Method and apparatus for monitoring and logging the operation of a distributed processing system

ABSTRACT

Method and apparatus for monitoring and logging the operation of a distributed processing system. A method for monitoring the operation of a distributed transaction system that is operable to process one or more transactions, each of which is comprised of a plurality of discrete processes, and which transaction as a whole is operable to perform a transaction on data when transferring data from a first location on a network to a second location on the network and the transaction comprised of operating on the data at intermediate nodes in the system with one or more of the plurality of processes during the transaction. First, a determination is made as to when a transaction has been initiated from the first location and has been transferred to the one of the intermediate nodes in the network. The initiation of the transaction is then logged at a central location on the network. A determination is then made as to when the initiated transaction has been completed by transfer of the processed data to the second location on the network from the last of the intermediate nodes in the network that has operated on the data. Completion of the transaction is then logged at the central location on the network.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.09/971,999, filed Oct. 5, 2001, entitled “Method and Apparatus forMonitoring and Logging the Operation of a Distributed ProcessingSystem,” which issues as U.S. Pat. No. 6,975,494 on Dec. 13, 2005, whichis a Continuation of U.S. Pat. No. 6,778,648, which issued on Sep. 7,2004, entitled “Method And Apparatus For Load Balancing a DistributedProcessing System,” which is a Continuation-in-Part of U.S. patentapplication Ser. No. 09/887,494, filed Jun. 22, 2001, entitled “MethodAnd Apparatus For Converting Data Between Two Dissimilar Systems” (AttyDkt No. ATTA-25514), which is a Continuation-in-Part of U.S. patentapplication Ser. No. 09/879,571, filed Jun. 12, 2001, entitled “Methodand Apparatus for Generating Unique Id Packets in a DistributedProcessing System” (Atty Dkt No. ATTA-25,515), which is aContinuation-in-Part of U.S. patent application Ser. No. 09/841,135,filed Apr. 24, 2001, entitled “System and Method for Transmission ofInformation Between Locations on a Computer Network with the Use ofUnique Packets,” (Atty Dkt. No. ATTA-25,441).

TECHNICAL FIELD OF THE INVENTION

This invention is related to data processing systems and theirarchitecture. In one aspect, it relates to a network component forretransmitting data packets in accordance with ID codes embedded thereinin a distributed manner.

BACKGROUND OF THE INVENTION

The classification and management of data is one of the most difficulttasks faced by corporations, government entities, and other large usersof information. Companies must classify their data in such a way to makeit easy and simple for buyers to find and purchase their products. Dataexchanges face a bigger challenge in that they must work with multiplecompanies and develop a comprehensive classification system for theirbuyers.

One common way to create a search/classification system for specificproducts is to access and use government and/or industry specificclassification systems (i.e., classification databases). However, noexisting classification database is comprehensive enough to address allthe issues associated with building a classification system. Theseissues include: uniform numbers for products that cross multipleindustries, restricting products from inclusion in classification, andnon-usage of slang or industry standard language to access or classifyproducts. The classification databases frequently do not address all theproducts, thus resulting in inconsistencies even when companies use thesame classification system.

Additionally, many of the various classification systems conflict witheach other. For example, a product might have several classificationnumbers if it crosses multiple industries. Still other companies mightuse third party classification systems approved by a governmentalentity. This program requires companies to pay multiple fees and gothrough a lengthy administrative process. Even then it may not cover allproducts in an industry. Companies must make a conscious decision toinitiate, implement and maintain these programs. These efforts can becostly, and for this reason, compliance is generally not high.

A need therefore, exists, for a data processing system whichautomatically generates identification codes for specific products.Preferably, companies could use the automatically-generatedidentification codes in place oftheir existing identification codes.More preferably, the use ofthe automatically-generated identificationcodes can be phased-in gradually as the of user base expands.

Under current practices, companies create search engines by developinghierarchies and families of products. They may create a thesaurus toencompass slang words. Companies often use drop down menus, key wordsand product description capabilities to enhance their systems. It isdesired to classify the data in such a way as to minimize the responsesgenerated by a search, and therefore more effectively guide the buyerthrough the system. However, under current practices, most exchangesoffer barely adequate search capabilities for their buyers. Buyers mustclick through numerous drop down menus and then sort through multipleentries to accomplish their objectives. In many instances the buyer willfail to find the product that they seek. These existing processes couldtherefore be characterized as cumbersome, time consuming, frustratingand ineffective. A need therefore exists, for a product classificationsystem which can facilitate simple, rapid and effective searching byprospective buyers.

Another challenging data management task is the transmission of databetween dissimilar systems. Even within the same corporate organizationit is very common to find different system types, applications and/orinformation structures being used. Transmitting data between suchsystems can be a time-consuming and expensive task. Under currentpractices, data transfer between dissimilar systems is often facilitatedby the use of customized software applications known as “adapters”. Someadapters “pull” data, i.e., extract it from the source system in thedata format of the host system or host application, convert the datainto another data format (e.g., EDI) and then sometimes convert it againinto yet another data format (e.g., XML) for transmission to thedestination system. Other adapters “push” data, i.e., convert the datafrom the transmission data format (e.g., XML) to an intermediate dataformat (e.g., EDI) if necessary, then convert it to the data format ofthe host system or application at the destination system, and finallyloading the data into the destination system. All of these adapter stepsare performed on the host systems using the host systems' CPU. Thus, inadapter-based systems, CPU load considerations may affect when and howoften data pulls can be scheduled. For example, data pulls may bescheduled for late nights so as slow down the CPU during daytime ONTP(on line transaction processing). A need therefore exists for a systemarchitecture which can allow the transmission of data between dissimilarsystems while minimizing the associated load imposed on the host systemCPU.

Network routers are known which direct data packages on a network inaccordance with ID codes embedded in the data packets. However, theserouters typically direct data packets between similar nodes on a singlenetwork. It is now becoming increasingly common to transmit data acrossmultiple networks, and even across different types of networks. A needtherefore exists for a router which can direct data over networks ofdifferent types in accordance with associated ID codes. A need furtherexists for a router which can automatically transform a data packethaving a first data format into a second data format.

It is well known that when large amounts of data are being transmittedbetween systems, a system error (i.e., stoppage) and/or data loss (i.e.,dropout) may occur. With conventional adapter-based systemarchitectures, debugging a system stoppage can be very challengingbecause of the large number of conversion processes involved, andbecause most systems do not have an integrated way to indicate the pointat which processing stopped, relying instead upon error logs. A needtherefore exists for a system architecture in which processing statusinformation is an integral part of the data packets transmitted over thenetworks.

Further, with adapter-based systems, even after the processes have beendebugged, it is often necessary to wait (e.g., until the time of daywhen host system CPU demand is low) to replace lost data in order toavoid adverse impact on the company's business. For example, if the hostsystem is used for OLTP (on line transaction processing) during the day,pulling bulk data from the host system in order to replace data lost ina previous data transfer may be delayed until the late night hours. Ofcourse, the delay in processing the data can have an adverse impact ofits own. A need therefore exists for a system architecture which allowsfor the replacement of lost data while minimizing the impact on thesource host system.

SUMMARY OF THE INVENTION

The present invention disclosed and claimed herein, in one aspectthereof, comprises a method for monitoring the operation of adistributed transaction system that is operable to process one or moretransactions, each of which is comprised of a plurality of discreteprocesses, and which transaction as a whole is operable to perform atransaction on data when transferring data from a first location on anetwork to a second location on the network and the transactioncomprised of operating on the data at intermediate nodes in the systemwith one or more of the plurality of processes during the transaction.First, a determination is made as to when a transaction has beeninitiated from the first location and has been transferred to the one ofthe intermediate nodes in the network. The initiation of the transactionis then logged at a central location on the network. A determination isthen made as to when the initiated transaction has been completed bytransfer of the processed data to the second location on the networkfrom the last of the intermediate nodes in the network that has operatedon the data. Completion of the transaction is then logged at the centrallocation on the network.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and theadvantages thereof, reference is now made to the following descriptiontaken in conjunction with the accompanying Drawings in which:

FIG. 1 illustrates an overall diagrammatic view of the system of thepresent disclosure;

FIG. 2 illustrates the detail of flow between elements of the system ofthe present disclosure;

FIG. 3 illustrates the flow of packets between elements in the systemand the conversion as the packets flow through the system;

FIGS. 4A-4D disclose diagrammatic views of the proprietary portion of atransaction packet;

FIG. 5 illustrates a diagrammatic view of databases at the host/clientand the conversion thereof to a proprietary routing ID packet;

FIG. 6 illustrates a diagrammatic view of one instantiation of thesystem of the present disclosure illustrating a transaction from a firsthost to a second host or client on the system;

FIGS. 7A and 7B illustrate two separate channels on the system;

FIG. 8 illustrates a flow chart depicting the initial operation ofgenerating the blocks of data for a transaction and scheduling thoseblocks for transmission;

FIG. 9 illustrates a flow chart depicting the data flow analysisoperation;

FIG. 10 illustrates a diagrammatic view of a transaction table that isformed during the transaction for analysis process;

FIG. 11 illustrates a flow chart depicting the export operation whereinthe data is polled and transmitted in packets;

FIG. 12 illustrates the operation of assembling the data packets;

FIG. 13 illustrates a diagrammatic view of a single channel and theprocesses performed in that channel;

FIG. 14 illustrates a diagrammatic view of two adjacent channels thatare utilized in completing a transaction or a process between an originand a destination.

FIG. 14A illustrates the joiner IDs for the two channels;

FIG. 15 illustrates a schematic diagram of three separate processsystems joined by separate channels;

FIG. 16 illustrates a diagrammatic view of the manner in which feeds arepropagated along a process chain;

FIG. 17 illustrates the process flow for the feeds in a given process ortransaction;

FIG. 18 illustrates a flow chart for the operation at each process nodefor determining from the feed the process to run and then selecting thenext feed;

FIG. 19 illustrates a diagrammatic view of three adjacent channels in asingle process flow;

FIG. 20 illustrates a diagrammatic view for a non-system host or originprocess node accessing a system process node;

FIG. 21 illustrates the process at the router for handling an out ofsystem process node that originates a transaction;

FIG. 22 illustrates a diagrammatic view of a simplified network forservicing a non-system node with the processes illustrated;

FIG. 23 illustrates an alternative embodiment of the embodiment of FIG.22;

FIG. 24 illustrates a more detailed diagram of the data packet;

FIG. 25 illustrates a detail of the preamble of the data packet;

FIG. 26 and 27 illustrate the hierarchal structure of the classificationsystem associated with the data packet;

FIG. 28 illustrates a diagrammatic flow of a classification operation;

FIG. 29 illustrates a flow chart for creating a data packet;

FIG. 30 illustrates a diagrammatic view for associating an input profilewith a previous data packet and creating a new data packet;

FIG. 31 illustrates a block diagram for layering of data packets;

FIGS. 32 and 33 illustrate block diagrams for two embodiments of acommunication system for conversing between two nodes with data packets;

FIGS. 34 and 34 a illustrate an example of communication with a datapacket;

FIG. 35 illustrates an overall diagrammatic view of the ID packetgenerator;

FIG. 36 illustrates a detailed diagram of the data profiling operation;

FIGS. 37 and 37 a illustrate a flow chart and data packet, respectfully,for the profile operation;

FIG. 38 illustrates a flow chart for the ID packet creation;

FIG. 39 illustrates a screen for the profile;

FIG. 40 illustrates a flow chart for the propagation operation;

FIG. 41 illustrates a flow chart for the acknowledgment operation;

FIG. 42 illustrates a flow chart for the look-up ping operation;

FIG. 43 illustrates a flow chart for the profile definition;

FIG. 44 illustrates a diagrammatic view of the ID packet flow during apropagation operation;

FIG. 45 illustrates the operation of propagating from one system to asecond system;

FIG. 46 illustrates a diagrammatic view of an internal propagation of anExtent;

FIG. 47 illustrates a diagrammatic view of the creation of an Extent;

FIG. 48 illustrates a flow chart for the operation of a propagatingExtent;

FIG. 49 illustrates a diagrammatic view of the transfer of ID packetsbetween two systems in a merger operation;

FIG. 50 illustrates a diagrammatic view of a table for two ID packetsfor an identical item or vendor;

FIG. 51 illustrates a block diagram for the merge operation;

FIG. 52 illustrates an alternate embodiment ofthe embodiment of FIG. 51;

FIG. 53 illustrates a diagrammatic view of the compare operation;

FIG. 54 illustrates a flowchart depicting the compare operation;

FIG. 55 illustrates a simplified schematic of the internal/externaloperation;

FIG. 56 illustrates a schematic view of the address linking between IDservers and different systems;

FIG. 56 a illustrates a simplified schematic of the propagation of anaddress through the network;

FIG. 57 illustrates a flow chart depicting the transfer of data from onesystem to another;

FIG. 58 illustrates a flow chart depicting the operation of creating theinternal database and populating the internal database downward;

FIG. 59 illustrates a flow chart depicting the operation of changing allof the data with a single “push” command;

FIG. 60 illustrates a block diagram of the Conversion Server;

FIG. 61 illustrates a flow chart depicting the operation of convertingdata between two dissimilar systems;

FIG. 62 illustrates a flow chart for the Extent that operates topush/pull data from a node;

FIG. 63 illustrates a diagrammatic view for a consolidation operationwith a Conversion Server;

FIG. 64 illustrates a flow chart depicting the consolidation operation;

FIG. 65 illustrates a flow chart depicting the update operation and theconsolidation operation;

FIG. 66 illustrates a diagrammatic view of the router;

FIG. 67 illustrates a transaction process through the system with thedata conversions illustrated;

FIG. 68 illustrates a flow chart for the initiation of a transaction;

FIG. 69 illustrates a diagrammatic view of multiple routers used in atransaction;

FIG. 70 illustrates a flow chart depicting the operation of reading thedata and assembling it into a transaction packet;

FIG. 71 illustrates a flow chart for the operation of the router;

FIG. 72 illustrates a flow chart for the polling process;

FIG. 73 illustrates a diagrammatic view of the monitoring operations;

FIG. 74 illustrates a flow chart for determining transaction load at anode;

FIG. 75 illustrates the load monitor operations;

FIG. 76 illustrates a diagrammatic view of two separate local networksinterfaced together;

FIG. 77 illustrates a flow chart for the “pull” operation from thearchive server; and

FIG. 78 illustrates a flow chart for the operation of the conversionserver as it interfaces with the archive server.

FIG. 79 illustrates a diagrammatic view of the monitoring and archivingfunctions;

You skipped FIG. 80

FIG. 81 illustrates a flow chart depicting local logging;

FIG. 82 illustrates a flow chart depicting global monitoring;

FIG. 83 illustrates a flow chart depicting a notification operation;

FIG. 84 illustrates a flow chart depicting the restart operation;

FIG. 85 illustrates a flow chart depicting the archive operation; and

FIG. 86 illustrates a flow chart depicting the archive of readoperation.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to FIG. 1, there is illustrated a system diagram for thepresently disclosed system. There are illustrated three transactionalsystems, 102, 104 and 106. Transaction system 102 is comprised of arouter 108 that is interfaced with a network mesh 110, which networkmesh 110 is local to the system 102. The network mesh 110 allows therouter 108 to interface with various system nodes. There is provided ahost system node 114 that is the node at which a transaction arises.Also attached to the network mesh 110 is an archival server 116 and aconversion server 118, the function of which will be describedhereinbelow. Since the host system 114, the servers 116 and 118, and therouter 108 are all in the same network mesh 110, they communicate in acommon protocol to that of the network mesh 110, and also may have theability to communicate over the network mesh 110 with other networkprotocols that presently exist and any future protocols that would bedeveloped at a later time. This allows data packets to be transferredbetween the various nodes on the network mesh 110.

The router 108 is also provided with various media interfaces 120 and122. Media interface 120 allows the router 108 to interface with aprivate network 124 which could be any type of private network such as alocal area network (LAN) or a wide area network (WAN). This privatenetwork 124 can have other systems attached thereto such that the router108 can forward data through this network 124. The media interface 122is interfaced with a global public network (GPN) 126, which is typicallyreferred to as the “Internet.” This allows the router 108 to interfacewith the GPN 126 and the multitude of resources associated therewith, asare well known in the art.

The system 106 is similar to the system 102 in that it has associatedtherewith a central router 128. The router 128 is interfaced with anetwork mesh 130, which network mesh 130 is also interfaced with auniversal ID server 132 and a universal web server 134. The router 128is also interfaced with the GPN 126 with a media interface 136. As such,the router 108 could effectively interface with the router 128 and thenetwork resources in the form of the universal ID server 132 and theuniversal web server 134, the operation of which will be describedhereinbelow.

The third system, the system 104, is comprised also of a central router136, similar to the routers 108 and 128. The router 136 is interfaced onthe local side thereof to a local network mesh 138. Local network mesh138 has associated therewith three host or transaction nodes, atransaction node 140 associated with a system A, a transaction node 142associated with a system B and a transaction node 144 associated with asystem C, the transaction nodes 140-144 all interfacing with the networkmesh 138. In addition, the system 104 has associated with its localnetwork mesh 138 a core ID server 146, an account ID server 148, aconversion server 150 and an archival server 152.

Router 136 is operable to interface with the private network 124 via amedia interface 154, interfaced with the GPN 126 via a media interface156 and also to a transmission medium 158 through a media interface 160.The transmission medium 158 is an application specific medium thatallows information to be transmitted to an end user output device 162through a media interface device 164 or to be received therefrom. Aswill be described hereinbelow, this end user output device might be afax machine, and the transmission medium 158 a telephone system or thesuch that allows data in the form of facsimile information to betransmitted from the router 136 through the transmission medium 158 tothe end user output device 162 for handling thereof. The transmissionmedium 158 may be merely a public telephone network (PTN) that allowsthe number of the end user output device 162 to be dialed, i.e.,addressed, over the network or transmission medium 158, the callanswered, a hand shake negotiated, and then the information transferredthereto in accordance with the transaction that originated in the accessto the transmission medium 158. The transmission medium could include asatellite transmission system, a paging transmission system, or any typeof other medium that interfaces between one of the routers and adestination/source device. This will be described in more detailhereinbelow.

In addition to allowing the router 136 to directly interface with an enduser device 162 via the interface 160, there is also provided a fifthtransaction node 166 that is disposed on the GPN 126 and has accessthereto via a media interface 168. The transaction node 166 is operableto interface with any of the routers 108, 128 or 136.

In operation, as will be described in more detail hereinbelow, each ofthe transaction nodes 114, 140, 142, 144, is able, through the use ofthe disclosed system, to complete a transaction on the system andutilize the system to send information to or retrieve information fromanother transaction node on the system. In the private network 124,there is illustrated a phantom line connection between the router 108and the router 136. In order to facilitate a connection between, forexample, transaction node 140 for system A and, for example, transactionnode 114 for system D, it is necessary to create a unique data packet ofID's that can be transmitted via the router 136 through the network 124and to, transaction node 114 for system D. This unique proprietarytransaction packet that is transmitted utilizes various distributedresources in order to allow this transaction packet to be processedwithin the system and transmitted over a defined route that is definedin an initial transaction profile that is stored in the system atvarious places in a distributed manner. This will be described in moredetail hereinbelow. Additionally, the router 136 could also allow one ofthe transaction nodes 140-144 to interface with the router 108 throughthe GPN 126 such that a transaction can be completed with thetransaction node 114 for system D. This would also be the case withrespect to interfacing with the universal ID server 132 or the universalweb server 134, the transaction node 166 for system E or with the enduser output device 162.

Each of the routers 108-128 and 136 have associated therewith a datacache 170, 172 and 180, respectively. Whenever a particular router inone of the systems 102-106 has data routed thereto, data may be cached,then processed either outside the system or internal to the system, orthe data is maintained in the cache for later transmittal. The generaloperation of a transaction would require one of the transaction nodes todetermine what type of transaction was being made and the destination ofthat transaction. If it were determined that the transaction would bebetween transaction node 140 and transaction node 114 on system 102, aunique transaction packet would be generated that would have uniquetransaction IDS associated therewith that defined the routing path inthe system and the transaction associated therewith while processingwhat needed to be done between the two transaction nodes. As will bedescribed hereinbelow, this transaction is distributed over the entiresystem, with only a portion thereof disposed at the transaction nodeitself. It is the unique transaction codes or IDS that are embedded inthe information that is sent to the system that allows the transactionto be carried out in a distributed manner at all of the various elementsalong the path of the transaction.

As a further example, consider that transaction node 114 for system Dutilizes a different database than transaction node 140, i.e., the twonodes are in general incompatible and require some type of conversion orcalculation to interface data and transactional information. With thetransaction determined at the transaction node originating thetransaction, and a unique transaction packet created with the uniquetransaction information contained therein, all the necessary informationto complete the transaction and the routing of data follows thetransaction packet through the system. This, in association withinformation disposed in other elements or nodes of the system, allowsthe transaction to be completed in a distributed manner. In particular,the transaction packet is transmitted to various nodes which performthose discrete functions associated with the transaction packet for thepurpose of converting, routing, etc. to ensure that the transactionpacket arrives at the correct destination and achieves the correcttransaction.

Referring now to FIG. 2, there is illustrated a diagrammatic view of thesystem 104 and a transaction between transaction nodes on the networkmesh 138, which network mesh 138 is illustrated as a general network. Itis noted that network mesh 138 could be any type of network, such as anEthernet, a satellite, a Wide Area Network or a Local Area Network. Thetransaction is illustrated as occurring between transaction node 140 forsystem A and transaction node 142 for system B. Although the details ofa transaction will be described in more detail hereinbelow, thistransaction is illustrated in a fairly simple form for exemplarypurposes. The transaction is initiated at transaction node 140 togenerate information that will be transmitted to transaction node 142for system B. When the transaction is generated, the type of transactionis determined, the manner in which the information is to be transmittedto transaction node 142 is determined and the route that it will take isdetermined, and all of the information is embedded in a transactionpacket. This is a predetermined transaction that is completed with theuse of IDS that are utilized by various systems on the network toappropriately route information and to possibly perform intermediateprocesses on the packet and the data associated therewith. Further,transaction node 140 has associated therewith information to allow thedata that needs to be transferred to be transferred in a predeterminedmanner in accordance with a known profile of how transaction node 142wants the transaction to be completed and in what form the data is to berun. For example, it may be that transaction node 140 desires to order aparticular product in a particular quantity from transaction node 142.The data associated with the transaction or transactions would beassembled, in accordance with a predetermined transaction profile asdetermined by the system beforehand and in accordance with a businessrelationship between the transacting parties, and forwarded to theappropriate location in the appropriate format to be received andprocessed by transaction node 142. These are transactions thattransaction node 140 typically receives and handles in their day-to-daybusiness. As such, all transaction node 142 desires to do is to receivethe transaction in a manner that is compatible with its operationalenvironment. By using various conversion algorithms, routing algorithmsand the such, the transaction can be effected between the two systems ina distributed manner.

Although not illustrated in FIG. 2, and as will be describedhereinbelow, there is an initial setup that defines a profile for atransaction and a profile for a transaction node in the system. Wheneverit is desirable for transaction node 140 for system A, for example, tocreate a business relationship with transaction node 142, this businessrelationship will be set up on the system as a transaction profile. Oncethe transaction node is set up, the various information that isnecessary for the two transaction nodes to converse will be set up onthe system and “propagated” over the system such that the transactionprofile is “distributed” about the system. This will be described inmore detail hereinbelow.

In the transaction illustrated, the first step is to create thetransaction packet and route it to the router 136. This is facilitatedover a path “A” through the network 138. The router 136 is then operableto examine the contents of the transaction packet and the IDS associatedtherewith with a look-up table (LUT) 202. In the LUT 202, the router 136determines that this transaction packet is associated with a particulartransaction and that the transaction requires that any information forthis type of transaction being received from transaction node 140 betransferred to the conversion server 150. The router 136 thenreassembles the packet and transfers this transaction packet over thenetwork 138 to the conversion server on a path “B” and also stores theinformation in its associated data cache. Router 136 has, as such,“handed off” the transaction to the conversion server 150 and thencreated a record in its local cache 180. (This could be stored in nonlocal cache also, such as at the archive server 152.) It is noted thatthe transaction packet may be converted at each node along the path,depending upon the transaction and the action to be taken at each node.

At the conversion server 150, the received packet from the path “B” isexamined to determine information associated therewith. The conversionserver 150 also has an LUT associated therewith, an LUT 204. Theconversion server 150 recognizes that the information came from therouter 136 and has a predetermined transaction associated therewithmerely from examining the IDS, processing them through the LUT 204 andthen determining what type of process is to be performed on the datapacket and the contents thereof and where to forward them to. Forexample, the operation of the conversion server could be as simple asconverting the data from an SML language to an XML language, it could beutilized to translate between languages, or any other type ofconversion. Primarily, the contents of the transaction packet andassociated data that was retrieved from the database associated withtransaction node 140, associated with the transaction therein, mayrequire conversion in order to be compatible with the destinationtransaction node 142. The conversion server 150 places the data in theappropriate format such that it will be recognized and handled by thetransaction node 142. The specific manner by which this conversion isachieved is that setup in the initial setup when the businessrelationship between the two transaction nodes 140 and 142 was defined.The reason that this particular conversion was performed is that theagreed upon transaction set these parameters in the system for thisportion of the transaction which is stored in the LUT 204 at theconversion server 150.

After the conversion server 150 has processed data in accordance withthe transaction IDS within the data packet, the transaction data packetis then reassembled with the destination address of the router 136 andtransferred back to the router 136 via a path “C,” which may also modifythe transaction packet to some extent, as will be described in moredetail hereinbelow. Router 136 recognizes this data packet as havingcome from the conversion server 150 and performs a look-up in the LUT202 to determine that this particular transaction, determined from thetransaction IDS associated therewith, requires data received fromconversion server 150 to be transferred to the transaction node 142. Thedata is then assembled in a transaction packet and transmitted totransaction node 142 along the path “D.” Additionally, the previouscached data in cache 180 is replaced by the new data that is forwardedto transaction node 142. In some instances, it is desirable to archivethe data associated with this transaction. This is facilitated by thearchive server 152, wherein the data transmitted to the transaction node142 along the path “D” is also transferred to the archive server 152along a path “D′.”

As will be described hereinbelow, the entire transaction is determinedby a unique transaction packet that has embedded therein routinginformation in the form of ID packets, data, etc. The ID packets areunique numbers that are recognized by each of the nodes in the networkto which it is routed. By recognizing an ID packet, the particularrouter 136, conversion server 150, etc., has information associatedtherewith that allows it to perform the portion of the transactionassociated with that particular node, i.e., the conversion server 150performs a conversion and then routes it back to the router 136. In thismanner, the originating transaction node need not embed all thetransaction information therein and actually effect a direct connection,through a network or otherwise, to the destination transaction node inorder to complete the transaction, nor does the originating transactionnode require all the transaction information to be associated therewith.As such, the transaction itself is distributed throughout the network ina predetermined manner.

Referring now to FIG. 3, there is illustrated a diagrammatic view ofthemanner in which the packet is modified through the transaction. Anoriginating transaction packet 302 is generated at the originatingtransaction node 140. This is then transferred to the router 136,wherein the router 136 evaluates the transaction packet, determineswhere it is to be sent and then converts the packet to a “conversiontransaction packet” 304, which is basically the transaction packet thatis designated by the router 136 for transmittal to the conversion server150 via the path “C” with the necessary information in the form of IDpackets, data, etc., that will be required by the conversion server 150to perform its portion of the transaction, it being noted that thetransaction packet may undergo many conversions as it traverses throughthe system. The conversion server 150 then processes the data containedin the conversion transaction packet and then, after processing,converts it to a router transaction packet 306 for transmission back tothe router 136. The router 136 then converts this to a destinationtransaction packet 308 for transmission to the destination. It is notedthat the conversion server 150, after receiving the router transactionpacket, has no knowledge of where the destination of the transactionpacket will be eventually, as it has only a small portion of thetransaction associated therewith. All it is required to know is that thetransaction packet requires a certain action to be taken, i.e., theconversion process, and then this transaction packet must be transmittedback to the router 136. Since this transaction packet always hasassociated therewith the necessary ID information as to the transaction,each node that the transaction packet is transferred to or through willrecognize where the transaction packet came from, what to do with thetransaction packet and then where to transfer it to. Each node then willtransfer the transaction packet to the destination eventually in a“daisy chain” manner.

Referring now to FIGS. 4A-4D, there are illustrated diagrammatic viewsofthe packet transmission which facilitates transmission of atransaction packet between transaction nodes or even nodes in a network.Prior to describing the formation of and transmission of the transactionpacket, the distinction must be made between a “data” packet and a“transaction” packet. In general, data is transmitted over a network ina packetized manner; that is, any block of data, be it large or small,is sent out in small “chunks” that define the packet. However, thepacket is a sequence of fields that represent such things as headers,footers, error correction codes, routing addresses and the data which issent as an intact “unit.” Sometimes, the data contained in the packet isactually a small portion of the actual overall data that is to betransmitted during a data transfer operation of some predetermined blockof data. These packets typically have finite length fields that areassociated therewith and some even have longer variable length fieldsfor the data. However, for large blocks of data, the data will bedivided up into smaller sub-blocks that can be sent in each packet.Therefore, for example, a large block of data would be sent to thenetwork controller for transmission over a compatible network to anetwork controller on a receiving device for assembly thereat. The blockof data, if it were large enough not to be compatible with a single datapacket, would be divided up into sub-blocks. Each of these sub-blocks isdisposed within a data packet and transmitted to the receiving devicewhich, once receiving it, will ensure that this data is then sequencedinto a combined block of data. If, for example, one of the data packetshad an error in it, this would be communicated back to the transmittingdevice and that particular data packet possibly retransmitted or theentire block of data retransmitted. Since each data packet has asequence number when sending a group of data packets that represent oneblock of data, the individual packets that each contain a sub-block ofdata can be reassembled to provide at the receiving device the entirepacket. This packetising of data is conventional.

With specific reference to FIG. 4A, there is illustrated the manner bywhich the data is actually transmitted. Typically, network controllersare arranged in multiple “layers” that extend from an application layerdown to a transport or network layer that inserts the data into a newformat that associates a data field 402 with a header 406. Theembodiment of FIG. 4A is referred to as an IPX data flow controller. Asnoted hereinabove, whenever a computer is attached to a network, itbecomes a node on a network and is referred to as a workstation. Wheninformation is sent between the nodes, it is packaged according to theprotocol rules set up in the network and associated with the networkcontroller. The rules are processes that must be complied with toutilize the operating system protocol layers—the application layer, thepresentation layer, the session layer, the transport layer, the networklayer, the data link and the physical layer—in order to actually outputa sequence of logical “1's” and “0's” for transmission on the networkmesh.

At the network layer, the data field 402, which was generated at theapplication layer, is associated with the header 406. This particularconfiguration is then sent down to the data link which is illustrated asa block 408 which basically associates the data field 402 with a UDPheader 410 and then translates this data field 402, UDP header 410 andthe IPX header 406 which is then translated into a new data field 412.This new data field 412 at the datalink is then associated with IPXheader 414 which is then again converted to a data field 414 associatedwith a media access controller (MAC) header 416 which is then compatiblewith the physical layer. The physical layer is the network mesh. Thisdata field 414 and header 416 are what is transferred to the network andwhat is received by the receiving device. The receiving device, uponreceiving the MAC header 416, recognizes an address as being associatedwith that particular receiving device and then extracts the data field414 therefrom, which is again utilized to extract the header 414 forexamination purposes and, if it is compatible with the device, then thedata field 412 is extracted and so on, until the data field 402 isextracted. Of course, data field 402 is only extracted if the datapacket comprised of the MAC header 416 and data field 414 is thatdirected to the particular receiving device. It is noted that alldevices on the network mesh will receive the data packet, i.e., they canall “see” the data packet traveling across the network mesh. However,the data will only be extracted by the addressed one of the devices onthe system. In this manner, a unique Universal Resource Locator (URL)can be defined for each device on the system. Typically, in an Ethernetenvironment, each network controller will have a unique serial numberassociated therewith, there never being two identical serial numbers inany network controller or network card for the Ethernet environment.

In the transaction packet, there are provided a plurality of smallerpackets that are referred to as “ID packets” that are generated in theapplication level. This basically comprises the data field 402. Thetransaction packet is formulated with a plurality of these ID packetsand data that are generated at the transaction node and modified atother nodes. This transaction packet, once formed, is transmitted to thenetwork level in such a manner that the appropriate header will beplaced thereon to send it to the appropriate location. Therefore, thesoftware or process running at the particular transmitting node on thenetwork will have some type of overhead associated therewith thatdefines the address of the source node on the network and also theaddress of the destination node. Therefore, when data is received by anyone of the nodes, it can recognize the defined field for the destinationaddress as being its address. Further, it can utilize the information inthe source address field, which is at a particular location in the datapacket, to determine where the data came from.

Referring specifically to FIG. 4B, there is illustrated a diagrammaticview of an ID packet 430. The ID packet 430, in the present disclosure,is comprised of a plurality of IDS, a core ID 432, a device ID 434 andan item ID 436, The core ID 432 is that associated with a particularentity on the network such as a corporation. For example, if acorporation had a profile set up, it would be assigned this particularcore ID when initiated. The device ID 434 is the unique ID of the deviceon the network. The core ID could be the corporation, and the device IDcould be the computer or program that is assigning item IDS. Forexample, if company ABC had an assigning device, a computer EFG, thecomputer EFG would be the creator of the ID packet. If device EFG wantedto assign a vendor ID to a particular vendor—the item, then vendor IDwould be set to HIJ. The value for the data packet would then beABC/EFG/HIJ. Note that the ID is actually not letters, but a combinationof codes and time stamps.

Each of the core ID 432, device ID 434 and item ID 436 are comprised oftwo blocks, a group block 438 and an individual block 440. The groupblock and the individual block 440 are comprised of a prefix 442, a timestamp 446 and a sequence number 448. The prefix is a sequence ofpredetermined prefixes that define various items associated with aparticular group or individual. For example, it could be that the setupof the profile define this individual as a vendor that had an accountwhich was a core ID and other various prefix values. As such, manydifferent companies or organizations could have the same prefix.However, once the prefix is defined, then the time that it is created isset in the time stamp 446 and then a sequence number is associatedtherewith in the field 448. Therefore, since only one entity will everassign the time stamp and sequence values, the entire block, 438 willcomprise a unique value or number or ID for that particular group. Forexample, if company A set up a profile, it would be assigned a uniquenumber that would always identify that particular company and this wouldnever change. As far as the individual block 440, this is a block thatfurther defines the core ID. For example, there may be five or sixdifferent divisions within a corporation such that this can be asubclassification. The notable aspect for this particular core ID 432 isthat it comprises a unique ID in the system and will define certainaspects of the overall ID packet 430, as well as the device ID 432, 434and item ID 436. When all three of these core ID 432, device ID 434 anditem ID 436 are combined, this defines a unique ID packet 430 that isassociated with various information such as transactions, messages,pointers, etc. These are set up originally in the universal ID server132 in a profile origination step (not described) wherein a particularoperation can be associated with the ID packet 430. This wouldessentially constitute a relational database somewhere in the system.Therefore, as will be described in more detail hereinbelow, when this IDpacket 430 is assembled into the transaction packet, it is onlynecessary for any node to examine each of the ID packets and determineif any of the ID packets define operations to be performed by thatparticular ID packet. For example, if the ID packet represented atransaction such as a conversion, then the conversion server 150 in, forexample, system 104, would recognize the particular ID packet indicatinga conversion operation and also it might require information as to thedestination node which is typically information contained in an IDpacket, among other information, which defines exactly the process thatmust be carried out. For example, it may be that information is to beconverted from one language to another which is indicated by an IDpacket merely by the ID itself. With a combination of that ID packetindicating that transaction and the unique ID packet associated with thedestination, the conversion server could make a decision that aparticular process is to be carried out. This is facilitated since arelational database will be associated with the conversion server 150that will run a particular process therein. It is not necessary to sendany information to the conversion server 150 as to exactly what must becarried out; rather, only the particular ID is necessary which comprisesa “pointer” to a process within the conversion server 150. Once theconversion is complete, then the process that is running can utilizeanother ID packet contained therein for the purpose of determining whichdevice in the node is to receive the results of the process and exactlyhow those results should be packaged in a new transaction packet, itbeing noted that the transaction packet can be modified many times alongwith the transaction as it traverses through the system.

Referring now to FIG. 4C, there is illustrated a diagrammatic view of atransaction packet 460. The transaction packet in FIG. 4C is illustratedas being a plurality of “stacked” packets referred to as IDP1, IDP2,IDP3 and IDP4, followed by a data field 462, followed by additional IDpackets, IDP5 and IDP6 and so on. This transaction packet 460 can haveany length, it being noted that the length is due to the number of IDpackets, those being fixed length, and possibly variable length datafield 462. By examining the ID packets as they arrive, which occurs in asequential manner, then each of the ID packets can determine whatfollows and what action should be taken. For example, IDP4 may be an IDpacket that defines exactly the length of the field 462 and what data iscontained therein. Typically, these will be in finite length blocks.

Referring now to FIG. 4D, there is illustrated a more detailed exampleof a transaction packet 464. In this transaction packet, there areprovided a plurality of ID packets, IDP1, IDP2, IDP3-IDP6, and so on.IDP1 is associated with a transaction packet defining a predeterminedtransaction. As noted hereinabove, this is merely a pointer to a processthat is defined in code on the recipient node, if that node is actuallygoing to utilize the transaction. It is noted that this transactionpacket IDP1 may be a transaction that is designated for another node.Following the IDP1 data packet is provided the IDP2 data packet which isassociated with a message number. A message number comprises the real IDof a line of data in the database of the transmitting transaction node.Followed by this message number would be a block number in the IDP3 datapacket followed by a block of data in a data packet 466. The messagenumber and block number define the sequence of the data packet 466 forlater assembly. This could then be followed by the data packet IDP4 foranother message number and IDP5 for a block number followed by a datapacket 468 associated with the message number and block number of IDP4and IDP5, respectively. This is then followed by the IDP6 data packetfor another transaction. Therefore, various message numbers, blocknumbers, data, transactions, process IDS, etc. can be transmitted in IDpackets, it being noted that all that is sent is a unique value that, inand of itself, provides no information. It is only when there is sometype of relational database that contains pointers that can becross-referenced to the unique ID packets that allows the information inthe ID packet to be utilized. If it is a transaction, as describedhereinabove, then that transaction could be carried out by recognizingthe pointer to that process disposed at the node that is processing thedata.

Referring now to FIG. 5, there is illustrated a detail of a database atthe source transaction node HI. This is by way of example only. In thisexample, there are provided three separate tables that exist in thedatabase. These are tables that can be formed as a result of thetransaction or exist as a result of other transactions. It is noted thatthese particular tables are in the “native” database of the transactionnode. Typically, the databases will always be arranged in rows andcolumns with a row identification address (RID) associated with eachrow. With the row address, one can identify where the data is for thepurpose of extracting the data, updating the data, etc. When data isaccessed from the database or is processed by the database with thesystem of the present disclosure, information is associated with eachrow of data in two separate proprietary columns, which columns areproprietary to the system of the present disclosure. They are a column502 and a column 504. The column 502 is a date stamp on a given row,such that the particular row when accessed can be date stamped as to thetime of access. A row ID that is proprietary is also associated with theaccessed row. Therefore, whenever a row is accessed, it is date stampedand assigned a row ID. In this manner, even if the data is reorganizedthrough a database packing operation or the such, the data can still befound. As such, a unique identification number for a given row can begenerated with the proprietary row ID or the proprietary RID and thedate stamp, such that a large number of proprietary numbers can berealized.

When the databases are generated and put in the appropriate formats, itis desirable to transfer data that is stored for the purpose of atransaction to actually facilitate or execute the transaction. Thisutilizes a unique “Extent” for that transaction, which Extent is definedby an arrow 506 that converts the data in the appropriate manner to aproprietary transaction packet 508. The Extent 506, as will be describedhereinbelow, is operable to determine how to process data, extract itfrom the various tables, even creating intermediate tables, and thenassemble the correct ID packets with the appropriate data in atransaction packet and transfer this transaction packet to the network.Since the transaction is a profiled transaction for the whole network,the entire decision of how to route the data and ID packets to thedestination and the manner in which the data is handled or delivered tothe destination is not necessarily determined in the Extent at the H1transaction node. Rather, only the information necessary to “launch” thetransaction from the transaction node H1 is required and which IDpackets are to be included. Once it is launched to network, this uniquetransaction packet travels through the network and is processed inaccordance with the unique ID packets embedded in therein.

Referring now to FIG. 6, there is illustrated a diagrammatic view of twotransaction nodes 602, labeled H1, and 604, labeled H2, in a system thatare both associated with individual routers 606, labeled R1, and router608, labeled R2. Router 606(R1) is interfaced with the transaction node602 through a local network 610, which also has associated therewith twoconversion servers 612 and 616, labeled C1 and C2, respectively. Therouter 606(R1) is interfaced with router 608(R2) via a network 618.Router 608(R2) is interfaced with transaction node 604 through a localnetwork 620, network 620 also interfaced with a conversion server 622labeled C3.

In operation, there will be a channel defined for any given transaction.This channel will define the path that is necessary to traverse an orderto “hit” all the necessary processing nodes in order to effect thetransaction in the appropriate manner and in an appropriate format thatwill be compatible with transaction node 604 when it arrives thereat.Similarly, if the transaction node 604 desires to utilize the sametransaction back to node H1, it would merely use the same channel but inthe reverse direction. Similarly, another transaction could be definedfrom the transaction node 604 to 604 directed toward transaction node602, requiring an additional channel. Of course, each of these wouldalso require a unique feed ID packet that would define the varioussoftware that generated the various channels, ID packets and the datapackets, as described hereinabove.

Referring now to FIGS. 7A and 7B, are illustrated graphical depictionsof two channels. In FIG. 7A, there is illustrated a channel from H1 toH2 labeled “0011.” This channel requires the data to be generated at H1and transferred to R1. At R1, a conversion operation is determined to berequired and the data is merely sent to converter C1 (after possiblecaching at the router.) At conversion server C1, the conversion isperformed and then it is reassembled and passed back to R1. At R1, it isdetermined that the data packet has arrived from C1, and the next stepis to send it to converter C2. Converter C2 then performs theappropriate conversion operation, based upon the feed ID packet and theother unique ID packets in the transaction packet, and then transfersthe transaction packet back to R1. At R1, it is determined that thistransaction packet must be sent to another router, which is router R2.When sent to router R2, the routing information could be global or itcould be network specific, i.e., the channels might be specific only tothe systems associated with the appropriate router. In a situation likethis, an intermediate “joiner ID” is generated that defines a particularrelationship. This is an intermediate ID that is created for the purposeof this particular transaction. This joiner ID then is generated and theinformation sent to the router R2 which indicates that router R2 is totransmit the transaction packet to H2. It is known in this particularchannel and transaction that the transaction packet is alreadyappropriately conditioned for receipt by H2 and H2 will receive thetransaction packet, and know what type of transaction is to be performedat H2, i.e., it is aware of the unique ID packets and their meaning,such as the feed ID, packet how to process information once received,etc. It therefore understands the parameters within which thetransaction is to be effected.

In FIG. 7B, there is illustrated another channel, channel “0022” forperforming another transaction from H2 over to H1. This channel requiresthat the transaction packet be sent from H2 over to R2 and then from R2over to C3 for conversion. After conversion, the transaction packet issent from C3 over to R2 and then from R2 over to R1 with a joiner ID,similar to that of FIG. 7A. At R1, the data is transferred directly toH1. If the transaction for this particular channel is to be transmittedback to H2 along the same channel, the reverse path would be utilized.

Referring now to FIG. 8, there is illustrated a flow chart forinitiating a transaction. When the transaction is initiated, it isinitiated at a block 802 and then a transaction table is created. Thistransaction table will have data associated therewith with rows of datatherein in a predetermined format that is associated with the nativedatabase of the transaction node. This transaction table will then haveeach row therein stamped with a proprietary date and a proprietary RID,as indicated by the function block 804. Thereafter, the transaction flowwill be analyzed, in a function block 806, to determine how the data isto be arranged and transferred. This transaction is then scheduled fortransmission, in a function block 808. This is facilitated with aprocess wherein various calls are created for each block of data in thedatabase, as indicated by a function block 810 and then a run ID iscreated in a function block 812. After the schedule has been generatedand queued, the program then flows to an End block 814.

Referring now to FIG. 9, there is illustrated a flow chart depicting theoperation of analyzing the transaction flow in the block 806. The flowbegins at a function block 902 to extract select data from the databaseand assign destination information and source information thereto, i.e.,determine that the transaction comes from H1 and flows to H2. Duringthis extraction operation, the type of extraction is determined, asindicated by block 901. It may be a partial extraction or a fullextraction. The partial extraction is one in which less than all of thedata for a given transaction is extracted, whereas the full extractionextracts all the desired data in a single continuous operation. Theprogram in function block 902 operates in a filter mode and flows to adecision block 916 to determine if there is a restriction on the datawhich, if determined to be the case, will result in filtering bypredetermined parameters, indicated by function block 918. Thisrestriction operation is a filter operation that sets various parametersas to how the data is “pulled” or extracted. If not restricted, or,after restriction (filtering), the program will flow to a block 920 to afunction block 904 to then assign a transaction ID to the data.Optionally, there could be assigned thereto a joiner ID in the eventthat it was determined the data should go across to systems and thejoiner ID were appropriate. This joiner ID will be describedhereinbelow. The program then flows to a function block 906 wherein amessage number is assigned to each transaction. This message number isassociated with a row of data. The program then flows to a functionblock 908 to determine block flow. Typically, in databases, the data isextracted in one large block of records. For example, a giventransaction may require 10,000 records to be transferred over thenetwork. However, it may be that the recipient transaction node desiresonly 500 records at a time as a function of the manner in which theyconduct business. This, as noted hereinabove, is what is originallydefined in the profile for the business relationship or thetransactional relationship between the two transaction nodes. This,again, is predefined information.

After determining the block flow, the program flows to a decision block910 to determine if this is to be a divided block flow, i.e., the blockis to be split up into sub blocks. If so, the program flows to afunction block 912 to assign a block ID to each sub-block, such that theblocks can be assembled at a later time. The program then flows to adecision block 914. If it is not to be divided, the program will flowfrom the decision block 910 to the input of decision block 914.

Decision block 914 determines if more data is to be extracted from thelocal database of the transaction node initiating the transaction and,if so, the program flows back to the input of function block 902 to pullmore data. Once the data associated with the transaction has beenextracted, the program will flow to a block 920 to return the operation.

Referring now to FIG. 10, there is illustrated a diagrammatic view of asample transaction table. The transaction table is basically comprisedof the message number, the transaction ID, the joiner ID (if necessary),the row ID and date with proprietary identification system and the blockID. Also, a RUN ID can be assigned to each block as it is beingprocessed. The row ID in a column 1002 and the date in a column 1004 isdifferent from the database defining row ID in that they are alwaysassociated with the row. The row ID in the database is defined asfunction of the database and can actually change through variousrearranging of the database at the transaction node.

Referring now to FIG. 11, there is illustrated a flow chart depictingthe operation of actually exporting the data from the transaction table.This is initiated at a block 1100 and then flows to a function block1102 to pull the first block in accordance with the Extent that isrunning. It should be understood that all of the flow charts from thestart of the transaction to the end of a transaction are associated witha predetermined transaction Extent. This Extent, as will be describedhereinbelow, is a sequence of instructions or codes that are downloadedto the particular node to allow the node to conduct its portion of thetransaction in the predetermined manner defined by the transactionprofile that is distributed throughout the system. Not all of thenecessary transaction information is contained here but, rather, onlythe information or the process steps necessary to create and transmitthe transaction packet out of the system in the correct manner.

Once the data is pulled in accordance with the Extent running on thetransaction node, the program will flow from the function block 1102 toa decision block 1104 to determine if a caching operation is to beperformed. If not, the program will flow to a function block 1106 toprocess the block as pulled. If caching is required, the program willflow to a decision block 1108 to determine if the caching is done,before transmitting the blocks and, when complete, the program will flowto a decision block 1108, along with the output of the function block1106. The decision block 1108 determines whether an encryption operationis to be performed. If the data is to be encrypted prior to transmittingover the network, the program will flow to a function block 1110. Ifnot, both function block 1110 and decision block 1108 will flow to theinput of a function block 1112 to assemble the data packet. It is notedthat the encryption operation is something that is optional and doesrequire the overhead in each recipient node to decrypt the data. Thisfunction will not be described with respect to the remainder of the dataflow.

Once at the function block 1112, the transaction packet is assembled.The program then flows to function block 1114 to determine if thetransaction packet is completely assembled and, once complete, theprogram will flow to a transmit block 1116.

Referring now to FIG. 12, there is illustrated a flow chart for thetransaction packet assembly operation, as initiated at a block 1202. Theprogram flows to the function block 1204 to determine the size of thedata packet, whether it is a small group of ID packets in thetransaction packet or plural ID packets in the transaction packet. Oncethe size of the transaction packet has been determined, the programflows to a function block 1206 to determine the router to whichinformation is to be transmitted. It is noted that more than one routercould be on a network. The router is determined, of course, as afunction ofthe particular Extent that is running, this being the path towhich the packet will be routed. Once determined, the program will flowto a function block 1208 to insert the feed ID and the channel ID. It isnoted that the feed ID and the channel ID are inherently a part of theExtent, this having been determined at the generation of the feed Extentwhich was generated during the profiling operation, as will be describedhereinbelow. The program then flows to function block 1210 to attach theRun ID thereto and then to a Return Block 1212.

Referring now to FIG. 13, there is illustrated a diagrammatic view of atransaction or process that is originated at an origin node 1302 fortransmission to the destination node 1304 on a single outgoing channel.As noted hereinabove, the outgoing channel defines the route and thetransaction. The origin node at 1302 utilizes a local Extent, indicatedby box 1306, to generate the transaction. In this transaction, there area number of IDS that are generated. One is a “RUN ID,” one is a “FEEDID,” and the third is a “CHAN ID.” Although there may also be other IDpackets that are generated, these three packets can basically define anentire transaction or process.

The origin node 1302, which can comprise the host node or the such,generates the transaction packet comprised of at least the RUN ID, theFEED ID and a CHANNEL ID and forwards it to a first process node 1306which processes the received transaction packet in accordance with theabove noted processes which then requires the transaction packet to bemodified and transferred to a second process node 1308 for furtherprocessing, which then forwards this to a third processing node 1310 andthen to a fourth processing node 1312 before final routing to thedestination node 1304. The destination node 1304, as describedhereinabove, can be the system router. Additionally, the router could beone of the processing nodes 1306-1312. This process will use a singleoutgoing channel for transferring a transaction packet from the originnode 1302 over to the destination node 1304. At the destination node1304, the information could be transferred out of the channel to anotherchannel, as will be described hereinbelow. Overall, this processingchannel is defined graphically as a block 1314. This graphicalrepresentation indicates that a transaction packet is generated and theprocess through various nodes in accordance with distributed processingdescribed hereinabove to route the transaction packet along variousprocessing nodes to the destination node 1304 for handling thereat.

Referring now to FIG. 14, there is illustrated a diagrammatic view oftwo channels adjacent to each other. In this embodiment, there isillustrated an origin node 1402 which is operable to generate atransaction packet, as described hereinabove, through two processingnodes 1404 and 1406 to a router 1408, labeled R1. This router R1 issubstantially the same as the destination node 1304 in the singleoutgoing channel noted with respect to FIG. 13. This combination of theorigin node 1402, the two processing nodes 1404 and 1406 and the router1408 comprise an outgoing channel. A second channel is associated with adestination node 1410. The overall transaction or process is operable togenerate the transaction at the origin node 1404 and route it finally tothe destination node 1410 for completion of the transaction. However,once the router 1408 has received the transaction packet, it then passesit over to a router 1412 labeled R2, which constitutes an incomingchannel for the destination node 1410. The router 1412 receives thepacket from router 1408 and passes it through two processing nodes 1414and 1416 to the destination node 1410. As noted hereinabove, the twosystems, the one associated with router 1408 and the one associated withrouter 1412 could handle the transaction packet and the ID packetsassociated therewith in a similar manner, i.e., that is, they couldutilize the same packet IDS. However, for security purposes, the originnode 1402 and the destination node 1410 utilize a different set of IDpackets referred to as joiner ID packets to transfer informationtherebetween. As such, within the outgoing channel associated withrouter 1408 and origin node 1402, there would be a defined set of systemassign IDS that would be proprietary to the origin node 1402. It may bethat the actual identification of these IDS is something that the originnode 1402 would not want to share with the destination node 1410.Therefore, the origin node 1402 and the destination node 1410 negotiatea relational database that associates an arbitrary joiner ID withvarious IDS at the origin node 1402 such that the IDS have no meaning inany system other than for the business relationship between the outgoingchannel and the incoming channel for the origin node 1402 anddestination node 1410, respectively. These joiner IDS are illustrated intables of FIG. 14A. You can see that router R1 has a table associatedtherewith wherein the joiner ID “0128” is associated with an ID packet“XXXX.” Whenever this joiner ID is received by router R2, a table forrouter R2 is examined to determine that this joiner ID “0128” isassociated with an ID packet “ZZZZ” therein. For example, it may be thatthere is a unique ID associated with origin node 1402 that defines it inan overall system. However, it may be that destination node 1410 definesthe origin node 1402 in a different manner, i.e., as “ZZZZ.” Rather thanredefine the joiner ID as “XXXX” in its system, it merely needs to havea joiner ID that defines the relationship between the two systems.Therefore, whenever the joiner ID “0128” is received as an ID packet,the router R2 will convert this joiner ID to the ID packet “ZZZZ” suchthat it now recognizes that ID packet as the vendor number of the originnode 1402 within its system. Other than within the system associatedwith destination node 1410, this has no meaning.

With respect to the joiner IDS, the joiner ID can be associated with thetransaction packet in any position along the processing path. Typically,the joiner ID is assigned at the origin node 1404 when running theExtent associated therewith, i.e., it is initially defined when the feedand the channel are assigned. However, it could actually be assigned atthe router 1408.

Referring now to FIG. 15 there are illustrated three separate processingblocks 1502, 1504 and 1506, similar to the processing block 1314. Eachof these processing blocks 1502, 1504 and 1506 represent a singlechannel and a processing system. For example, processing node 1502 couldrepresent a single company and its associated router, conversion server,ID server, archival server and host node. When performing a transactionto transfer to another system, the transaction packet is generatedwithin the processing node 1502, processed therethrough in accordancewith the distributed processing system as described hereinabove and thenoutput from the processing block 1502 over to a second channel 1508 forrouting to the processing block 1504. The processing block 1504represents a third channel and an independent and self-containedprocessing block. For example, the processing node 1504 may be anintermediate processing node that allows independent processing of atransaction or processing event for transfer to the processing block1506. This could be, for example, a satellite system that constitutes anintermediate processing step. Once the transaction has been processedthrough the third channel, this is then transferred to a fourth channel1510 for transfer to the block 1506, which comprises a fifth channel.Each of these channels and each of these processing blocks compriseseparate distinct processing operations which all operate on the sametransaction packet (although the transaction packet may be modifiedsomewhat). Initially, the processing block 1502 originates at anoriginating node therein the transaction. This transaction has a channeland feed associated therewith, which channel comprised all of thechannels from the origin to the destination at processing block 1506.

Referring now to FIG. 16, there is illustrated a diagrammatic view ofhow the channel IDS and the feed IDS change as the transaction packet isprocessed through various processing nodes. As described hereinabove, achannel is defined as the route that a transaction path is to takethrough the various processing nodes. Since the processing isdistributed, the transaction packet must be routed to each node in orderthat the appropriate processing be carried out on that transactionpacket. Since the processing is predefined with respect to the channelID, very little information needs to be disposed within the transactionpacket in order to effect the processing. This transaction packet andthe packet IDS associated therewith in the form of the feed ID, thechannel ID, etc., define the portion of the processing that is to becarried out at each processing node, i.e., these constituting processpointers at each processing node. With respect to the channel ID, thisbasically remains the same in the transaction packet as the transactionpacket traverses a group of processing nodes. However, the feed ID willchange. The feed ID basically constitutes an instruction that isgenerated at one processing node for transfer to the second processingnode that defines the processes that are to be carried out. In general,this feed ID is a “tracer” that follows the process to flow from node tonode. As such, when one node receives a transaction ID from anotherprocessing node, it recognizes that the process is that associated withthe channel ID, but it also recognizes where in the process thetransaction packet is. For example, a router may handle a transactionpacket a number of times in order to effect transfer to one or moreconversion servers, effect transfer to an ID server, etc. With the useof the feed ID, the router now has knowledge of what process is to becarried out in the overall transaction process when it receives thetransaction packet from a given processing node. Additionally, anotheraspect that the feed ID provides is the tracing function wherein afailure at any point along the process path can now be tracked to theprevious process that was carried out.

With specific respect to FIG. 16, there are provided a plurality ofprocessing nodes 1602 labeled N1, N2, . . . , NK. Each of the processingnodes 1602, as described hereinabove, carry out a portion ofthe overalltransaction process which was predistributed to the processing node.Each of the processing nodes 1602 carries out a plurality of processes,labeled P1, P2 and P3 for exemplary purposes. It should be understoodthat any number of processes could exist at a particular processing node1602 that could be associated with a given channel ID or multiplechannel IDS for many other transactions apart from the currenttransaction. It is noted that each processing node can handle manydifferent processes and transactions. Once a transaction ID packet isconfigured, each processing node will receive that transaction packet,examine the transaction packet and determine exactly which process mustbe performed on that transaction packet, all of the effected with only afew ID packets of a fixed length.

When the transaction is initiated, it is initiated at the origin node,illustrated as a node 1604 for generation of a feed ID and a channel ID,labeled FEED1 and CHID1. This indicates at the origin node 1604 thatthis transaction packet is. to be transferred to processing node N1.When processing node N1 receives the transaction packet, it recognizesthat the process to be carried out is defined by the feed ID and it hasassociated therewith a FEED1 block 1606 that defines the process that isto be carried out. This block 1606 then can select between the availableprocesses P1-P3 for application to the transaction packet. Once atransaction packet has been processed in accordance with the selectedone of the processes (it may possibly require more than one process forthe processing), then the feed number is changed to the next feed ID,FEED2, and then the transaction packet is transferred with the samechannel ID, CHID1, to the next processing node, node N2. At this node,the processing node recognizes that this is the FEED2 feed ID andprocesses the data in accordance with a block 1608 for this particularfeed ID. Again, this selects between a plurality of processes foroperation on the transaction packet. Once processed, then the feed ID isincremented and the transaction packet transferred until it reaches thelast processing node in the processing chain, the processing node NK. Atthis node, this processing node will receive the feed ID, FEEDK, and thesame channel ID, CHID1. This will be processed with processing block1610 in accordance with the feed ID to select the process that is to beapplied to the transaction packet and then this is transferred out tothe destination.

It can be seen that this “hopping” operation allows the transactionpacket to be passed from one processing node to another. By incrementingthe feed ID along the processing chain, each processing node candetermine uniquely what process is to be carried out in the overallprocessing chain. However, it should also be understood that the feed IDprovides this tracer operation, but could be eliminated. It could bethat all that is required is the channel ID. Each processing node wouldreceive the channel ID and the processing associated therewith could beindicative of the process to be carried out by recognizing where thechannel ID came from. Therefore, an entire transaction could be carriedout with a single ID packet. For example, suppose that a transactioninvolved a conventional normal transaction between two business entitiesthat involve the transfer of 100 widgets to a particular warehouse. Oncethe business relationship is defined between two companies, then asingle channel ID could be transferred to the destination company which,upon receipt, would recognize that a particular transaction was to becarried out in a particular way for this particular vendor. It may bethat there are some conversions that are required during the process,which will require the ID packet to be transferred to a conversionserver to possibly assign a joiner ID to the channel Id in order toprovide some security to the system to prevent actual information at theorigin in the form of its unique vendor ID, etc., to be transferred tothe destination node. As such, it may be that some type of conversionoperation would be required to assign a joiner ID during the process inthe first company's system for transfer to the second company's system.It is noted that a company system is that defined by a router, a networkmesh, an ID server and a host node. Typically, the ID server, the hostnode, the conversion server, and the network mesh are all typicallyassociated and “owned” by a particular company.

Referring now to FIG. 17, there is illustrated a diagrammatic view ofhow the feed is incremented. This is initiated at a start block 1702 andthen proceeds to various feed blocks for the feeds FEED1, FEED2, . . . ,FEEDK. The process must go through each of the feed blocks and, at eachof the feed blocks, carry out the associated process. Therefore, thetransaction packet in effect not only carries a channel ID that can beutilized at a particular processing node to determine what transactionis being processed but also receive intermediate instructions toindicate what processes in the transaction are to be carried out. Asnoted hereinabove, it may be that the router is involved in the actualtransaction a number of times. Although a plurality of processes arepredetermined as being associated with the given transaction, theprocesses that are applied to the transaction packet are determined as afunction of where in the process the transaction is. The feed IDSindicate the position in the transaction for the purposes of determiningwhich predetermined transaction processes are to be applied to thetransaction packet when received at a particular processing node.Additionally, the feed IDS also provide for some failure analysis in theevent that a failure occurs. For example, in FIG. 15, one could examineany transaction or process from the origin to the final destination atany place in the process and determine where in the process it was.

Referring now to FIG. 18, there is illustrated a flow chart depictingthe operation of running the process at a given process node. Theprogram is initiated at a block 1802 and then proceeds to a functionblock 1804 to read the feed ID received in the transaction packet. Theprogram then flows to a function block at 1806 to run the process orprocesses associated with that feed ID and then to a decision block 1808to determine if all the processes have been run. If not, the programcontinues running processes in the block 1806 and, when complete, theprogram flows to a function block 1810 to increment to the next feednumber and then transmit the transaction packet to the next processingnode, as indicated by a return block 1812.

Referring now to FIG. 19, there is illustrated a diagrammatic view of aplurality of channels which indicate processing from an origin to adestination in each channel and then handing off to a second channel orsecond system. These are defined as channels CH1, CH2 and CH3. Inchannel CH1, there is provided an origin node 1902 and a destinationnode 1904 with two processing nodes 1906 associated therewith. In thesecond channel, CH2, there is provided an origin node 1908 and adestination node 1910 with three intermediate processing nodes 1912. Inthe third channel, CH3, there is provided an origin node 1914 and adestination node 1916 and three processing nodes 1918. The transactionis initiated at the origin node 1902 for final transmission to thedestination node 1916. However, between the destination nodes 1904 and1908, there is provided a line of demarcation 1920, with a similar lineof demarcation 1922 disposed between destination node D2 and origin node1914. The destination node 1904 could be a router and the origin node1908 could be a router in channel CH2. The line of demarcation 1920indicates that the first channel, CH1, basically “hands off” thetransaction to the second channel CH2 which processes the transaction inaccordance with a predetermined process set forth therein in adistributed manner across the various processing nodes for handing itoff to the third channel, CH3. Each of the line of demarcations 1920 and1922 define distinct boundaries such that the transaction packet can beconsidered independently handled for each of the channels. For example,it may be that in order to transfer from CH1 to CH2, a joiner ID isprovided. When handing off from destination 1910 to origin 1914 acrossline of demarcation 1922, a second joiner ID′ may be required.

Referring now to FIG. 20, there is illustrated a diagrammatic view ofone of the systems of 102-108 wherein a non-system node 2002 isinterfaced with the system 104 through a network 2006, which interfaceswith the router 136. The non-system node 2002, since it is not part ofthe overall system 104, is not identified in the system per se withoutsome processing in the system 104. In general, the non-system node 2002first must be identified and the transaction associated with its accessto the router 136 identified. Once this identification is made, then thenecessary transaction packet is assembled and the transaction conductedin accordance with the process described hereinabove. For example, thenon-system node 2002 will initiate a transaction merely by contactingthe router 136. This could merely be the transmission of a request to aspecified URL of the router 136 on the network 2006. The router 136,upon recognizing the URL of the non-system node 2002, i.e., the sourceURL, would recognize that a transaction is being initiated. The routerwould then create a transaction packet and route it to the conversionserver 150. The conversion server 150 would then convert informationreceived from the non-system node 2002 over to a format compatible witha transaction to be conducted with, for example, transaction node 140 onthe network mesh 138 in the system 104.

As an example of a transaction, consider that the non-system node 2002wanted to send an order via e-mail to transaction node 140. Tofacilitate this, non-system node 2002 would fill out a form in-apredetermined order with information disposed in predetermined fields.This e-mail would then be routed to the router 136. The router 136 wouldrecognize the source of the e-mail and the fact that it was an e-mail.By recognizing both the source of the e-mail and the fact that it ise-mail, the router 136 would now recognize a transaction. It wouldcreate a form ID for the non-system node 2002, which would define thetype of form that is to be routed to the conversion server 150, andvarious other IDS that are associated with the transaction. This formand the form ID, in addition to other identification information in theform of ID packets, would be sent to the conversion server 150. Theconversion server 150 would then extract the information from the formin accordance with the form ID pointer, and convert this to informationassociated with the transaction. This would then be transferred totransaction node 140.

Referring now to FIG. 21, there is illustrated a flow chart depictingthe operation of the router 136 when receiving information from withinthe system and from outside of the system. The operation of the router136 is operable to receive data in the form of packetized data from thenon-system node 2002. This is indicated at decision block 2102. Theprogram then proceeds to decision block 2104 to determine whether thisis a system packet. If so, then this indicates that this is a systemnode and the program will proceed to a function block 2106 to processthe received transaction packet in a normal mode. If it is not a systempacket or transaction packet, the program would flow to a function block2108 to convert the packet to a system packet and then to the functionblock 2106.

Referring now to FIG. 22, there is illustrated a block diagram of asimplified embodiment of FIG. 20. In this embodiment, there isillustrated a situation wherein the non-system transaction node 2002 cando nothing more than access the router 136 and transfer informationthereto. As such, the router 136 must have some type of ID process,indicated by block 2202, by which to recognize the non-system node 2002and associate the transaction packet therewith, which involves the useof a form ID, as described hereinabove. Once the transaction packet iscreated by the router 136, then the transaction packet is routed to theconversion server 150 and a conversion process, as indicated by block2204, is run and the information received from the non-system node 2002converted to the appropriate format to complete the transaction.

Referring now to FIG. 23, there is illustrated an alternate embodimentof the embodiment of FIG. 22, wherein the non-system transaction node2002 has software associated therewith that allows it to form thetransaction packet. The non-system node 2002 has an ID process block2302 associated therewith that allows the non-system node 2002 to createa transaction packet. The non-system node 2002 has a definite ID on thesystem which has been defined in the original setup wherein the IDprocess in block 2302 was created and “pushed” out to the non-systemnode 2002. Whenever a transaction is to be implemented, the ID processis run and a transaction packet assembled. This transaction packet isthen forwarded to the router 136, in accordance with information in thetransaction packet. This is due to the fact that the transaction packetcreated by the ID process 2302 has a channel ID and the such containedtherein.

Once the router 136 receives the transaction packet, it recognizes thistransaction packet as one that exists on the system and routes it inaccordance with a routing process in a process block 2304. Thereafter,this transaction packet is modified, if necessary, and routed to theconversion server 150 for processing thereby. The routing to theconversion server 150 is in accordance with the channel definition setforth in the ID process 2302. Thereafter, the information is processedas described hereinabove with respect to FIG. 22.

ID Packet

Referring now to FIG. 24, there is illustrated a more detaileddiagrammatic view of the ID packet that constitutes the proprietaryportion of a transaction packet that is transferred over the network, itbeing noted that this ID packet is typically embedded within a datatransmission between the network with all of the commensurate overheadassociated with such a transfer. As was described hereinabove, this IDpacket represents the smallest fixed length portion of a transactionpacket.

The ID packet is divided into three sections, a core ID section 2402, adevice ID section 2404 and an item ID section 2406. Each of the sections2402-2406 are divided into two sections, a “Group” ID and a “Individual”ID section. A detail is illustrated of the core section 2402. Each ofthe Group and Individual sections are comprised of three sections, apreamble section 2408, a time stamp section 2410 and a sequence section2412. As described hereinabove, the preamble section 2408 comprises aclassification section that is comprised of a plurality of“classifiers.” The time stamp section 2410 and the sequence section 2412provide a unique value that, when associated with a classifier section2408, provides a unique group value for the core section 2402. TheIndividual section is also organized as such. In the preamble section2408 of the Group section, it can be seen that there are a number ofclassifiers associated therewith. Of these, one classifier will alwaysbe the classifier “G.” There can be multiple other classifiers, it beingunderstood that the number of classifiers is finite. As will bedescribed hereinbelow, each of these classifiers is comprised of asingle alpha character, there being twenty-six alpha characters, each ofwhich can be represented by an ASCII value which is a finite lengthvalue. Of course, this limits the number of values to twenty-six foreach classifier field. There could be any type of value system utilized,it only being necessary that the field be a fixed length. For example,if the field were defined as a digital word having a four bit length,this would provide 2⁴ values. With respect to the preamble 2408 on theIndividual section, this also has a finite number of classifier fields,one of which will be the classifier “I” designating this as anIndividual ID.

The core ID 2402, device ID 2404 and item ID 2406 are illustrated inTable 1 as follows: TABLE 1 CORE (WHO) DEVICE (WHERE) ITEM (WHAT)Corporation or Assignee of the Packet, Object, e.g., article, net Entitye.g., computer, phone, etc. address, real estate property, etc.

The core ID 2402 is directed toward the basic owner of the ID packet.This, for example, could be a corporation, such as Corporation ABC. Thedevice ID is associated with the device that assigned the values in thepacket. For example, this could actually be the ID of the computer, thephone, etc. that actually was responsible for assigning the packet. Theitem ID is the subject of the data packet or the object, i.e., anarticle of commerce, a network address, a real estate property or thesuch. This is referred to as the “Who, Where, What” aspect ofthe IDpacket. For example, Corporation ABC is originally defined as the ownerof the ID packet. A unique core ID is initially associated with the ABCcorporation wherein a defined classification preamble 2408 is associatedtherewith and then a unique time stamp and sequence number. Thisclassifying preamble 2408 may actually be identical to theclassification associated with other corporations in the system.However, once the time stamp and sequence number are associated with thepreamble 2408, this core ID becomes unique as to that corporation orentity against others. When an object or item is being incorporated intoan ID packet, i.e., an ID packet is being created to uniquely definethat item in the system, there is some device on the system thatactually creates this ID packet. For example, it might be that acatheter is being uniquely defined in a company. There will be possiblya computer terminal on which the information is entered. This computerterminal has an ID in the system and it is this ID that comprises thedevice ID. Therefore, once the ID packet is created, the entity(corporation) then owns the ID packet. The object, i.e., the catheter,is classified and is also known which device assigned the ID packet orcreated the ID packet.

Referring now to FIG. 25, there is illustrated a more detailed diagramof the preamble 2408. The preamble 2408, as described hereinabove, iscomprised of a plurality of fields. These are referred to in FIG. 25 as“F1, F2, F3, F4, F5, . . .” There are a fixed number of fields for thepreamble 2408 which, in the present disclosure, are fixed for each GroupID and Individual ID for each of the core, device and item IDS. However,it could be that the fields differ between preambles, the onlyrequirement being that they do not differ between ID packets. A typicalfive field preamble section of an ID is illustrated in Table 2 as itexists in the database, understanding that more fields may beincorporated. TABLE 2 F1 F2 F3 F4 F5 TS/SEQ CONTENT A B Z C W XXXX — C TQ I C XXXX — F L A K L XXXX — G M B R S XXXX —

With reference to Table 2, it is described hereinabove that each fieldhas an alpha character associated therewith. This alpha character has apredefined relationship for the classifier. For example, if a field wereassociated with the type of ID, there could be two values, oneassociated with a permanent ID and one associated with a joiner ID. Thiswould therefore be a field having only two values. It could be that thisutilized the alpha characters “P” and “J.” However, it could use anyalpha character (number, character, symbol, etc.), it being recognizedthat the value or relationship (meaning) of the characters isunimportant; rather, it is the relationship of that packet disposed inother locations in the system that is important. In TABLE 2, it can beseen that the database associated with a particular ID has associatedtherewith the fields in the preamble, the time stamp/sequence field(TS/SEQ) section in addition to a content column. The content columndefines what this preamble is associated with. For example, if this werethe Group ID in the core ID 2402, then this could refer to, for example,a content of “chemical corporations.” If this were Corporation ABC, thenthe Individual ID would have a preamble field that might be common withother individual corporations but the TS/SEQ section would be uniqueonly to that corporation and the content associated with that particularcorporation would have the term “Corporation ABC” in the content column.It may be that there are ten corporations that have identical preamblesbut different TS/SEQ values and, therefore, the core ID 2402 would beunique to that corporation. Each of the Group ID and Individual IDS forthe core, device and item IDS in the ID packet would be configuredsimilarly.

As will be described hereinbelow, although each of the fields in thepreamble 2408 is defined as having only 26 values due to the choice ofan alpha character as the classifier, one of the fields can be combinedwith the TS/SEQ value to provide a larger value associated therewith.Since the TS/SEQ value can comprise a unique and very large number, itdoes not constitute a classifier as such. By combining the twenty-sixalpha numeric values each with the TS/SEQ value, the number ofclassifiers for that particular field becomes very large. For example,if one wanted to define a field in the preamble for the item ID 2406 asthe field that defines the item, more than twenty-six item classifierscan now be provided. As a simple example, it could be that there are aplurality of catheter types in a company such as a pulmonary catheter, acardiac catheter, etc. If there are more than twenty-six of these typesof catheters, there would be required more than twenty-six classifiervalues. By combining an alpha character with the time stamp, the numberof available classifiers can be increased in value.

Referring now to FIG. 26, there is illustrated a diagrammatic view ofthe classification scheme. There are illustrated four fields that arebeing classified in a preamble, it being understood that more or lessfields could be defined for the preamble structure, with only threevalues illustrated for each field. However, each of these values can beconditional upon the previous path, as will be described hereinbelow. Inthe field F1, there are illustrated three classifier values, A, B, C.The classifier of interest in field F1 is “A.” There are illustratedthree paths from this classifier, since field F2 is only associated withthree classifiers, these being again, A, B, and C. It should beunderstood that the classifications being associated with the classifierA is not necessarily the same classifier associated with the classifierA in field F1. Also, the classifier B in field 1 may also point to threeseparate classifiers A, B and C in field F2. However, it should beunderstood that the classifier A in field F2 that the classifier B infield F1 could point to may not be the same as classifier A in field F2pointed to by the classifier A in field F1. The classifier in any one ofthe fields below field F1 has a value that may be conditioned upon theclassifier in the previous field from which it derives. It can be seenthat each of the classifiers in field F2 will point to one or moreclassifiers in the next field F3, there being illustrated three, A, Band C. Further, field F4 further expands this will three classifiers, A,B and C for each of the classifiers in field F3. Again, although thereare illustrated as multiple classifiers A in field F3, they are notidentical in value or classification function but, rather, they areunique to the associated path.

With reference to FIG. 27, there is illustrated a single path through agiven preamble of a field width of four. In the Group ID, for example,the preamble may be classified as “A” in field F1 and it may point toclassifier “B” in field F2. Although the path could go to classifiers“A” or “C” only one path is selected. At field F2, classifier B pointsto classifier “A” in field F3 and classifier “A” in field F3 points toclassifier “B” in field F4. Therefore, once it has been determined thatfield F1 has classifier A, then the next determination must be which ofthe classifiers in field F2 associated with classifier A in field F1will be selected. It is this association of classifiers in a lower fieldwith those in an upper field that defines the classification scheme.Again, it could be that classifier “B” in field F1 could point to aclassifier “B” in field F2 that is different than that associated withclassifier “A” in field F1. However, it could be that some fields haveidentical classifiers for each of the above fields. For example, in theGroup ID, the last field will always be “G” defining the Group ID assuch (not a conditional classifier.) The individual ID will always havea “I” in the last field thereof defining it as such. Therefore, thereneed not be any association between fields though there can be anassociation. With respect to the Individual ID, this follows the samepath as the Group ID with the exception that it is defined as havingvalues of “D,” “E,” and “F.”

The ID that is generated will be stored in a table in the database ofthe ID server with alpha titles that can be searched, in associationwith the code associated therewith. A typical table in the database isillustrated in Table 3. In Table 3, the field F1 is associated with anID that is either a permanent ID or joiner ID. This is referred to asP/J in one column, this is defined as a permanent or joiner field withthe code associated with the permanent field being a “P” and the codeassociated with the joiner field with the joiner value being a “J.” Thesecond field F2 is associated with different types of devices areIndividual IDS or Group IDS, defined, in this embodiment as a profiletype, a network type or a system type. Therefore, the one column willdefine the type as being profile, network or system and the codeassociated with the profile type will be “F,” the code associated with aprofile type would be “P,” with a network type would be “N” and with asystem type would be “S.” Field F3 is associated with an item whichcould be a type of computer such as an Apple computer, an item such as acatheter, a URL for a network address or the name of a system such asAVC or with a system referred to as a PPLL, this basically being anacronym for some type of system in the industry, as an arbitraryexample. In this example, the code is the combination of an alphacharacter plus the time stamp for that row, to provide a large number ofvalues therefor. In field F4, this is the category of the ID which, inthis example can either be a core ID or a vendor ID. If it is a core ID,it will have a code of “C” and if it is a vendor ID, it will have a codeof “V.” There will also be a time stamp associated with each row. It canbe seen that there are two IDS having identical values in all of thesefields with the exception that field F3 is associated with differentcatheters. As such, the code value would be distinguishable between thetwo because the code P+TS is associated with a different time stamp.This is what makes these two IDS distinct, even though they areassociated with the same item, they are both vendor IDS, they are bothpermanent IDS and they are both profile IDS. By utilizing the time stampin association with a alpha character, a much larger number of items canbe defined for this particular field.

Referring now to FIG. 28, there is illustrated a diagrammatic view ofthe method in which the data packet is created and the databasepopulated with the data packet. Initially, a profile screen 2802 isprovided which provides a plurality of user modifiable fields 2804 thatallow the user to insert information. Each of these fields is utilizedfor the classification operation. Sometimes, this is an interactivesystem wherein inserting information into one field will result inanother type of field being made available. For example, if somebodywere classifying a data packet as being associated with a network, itmight be that the URL of the network were provided as a possible inputfor another classifier, whereas that particular classifier, the URL,might not be appropriate for a previous classifier.

Once the user has inserted all of the necessary information, then theflow would move to a block 2806 wherein the information that is input bythe user would be classified into the preamble of the appropriate ID inthe data packet. This, as described hereinabove, would be required inorder to classify all of the IDS in the ID packet. For example, whenfilling the profile, a corporate name would be specified whichautomatically would pull up the core ID for that corporation. Of course,the device that is being utilized to fill in the profile would alreadybe known and would constitute the device ID. The remaining portion ofthe profile 2802 would be utilized for the purpose of providing the itemprofile. The classifier would assemble all of this information and thenflow to a block 2808 wherein the data packet is populated and thedatabase is populated, as indicated by block 2810. This population ofthedatabase would provide information associated with the ID packet, as setforth in Table 3, such that all of the information necessary to identifya ID packet is contained therein. Table 3 is as follows: TABLE 3 F1 F2F3 F4 P/J Code TYPE Code ITEM Code CATEG Code F5 Perm P Profile P AppleD + TS CORE C — Perm P Profile P Cath P + TS VN V — Perm P Profile PCath P + TS VN V — Perm P Network N URL P + TS VN V — Perm P System SAVC A + TS VN V — Join J Profile P Cath Z + TS CORE C — Join J Profile PCath F + TS CORE C — Join J Network N URL L + TS VN V — Join J System SPPLL N + TS VN V —

As such, the ID packet now provides a method to “point” to a specificrow in the database, due to the fact that all of the preambles and thetime stamps exist. Although Table 3 illustrated only a single ID in theID packet, it should be understood that each ID packet is represented byall of the IDS, which comprise a single row in the database. Thisdatabase is typically populated at the ID server and then the ID server,as described hereinabove, “pushes” all of the ID packets in the databaseto the respective account servers such as the conversion server, therouter, etc. Also as noted hereinabove, some of these ID packets couldidentify processes. In this situation, it might be that all of theinformation in the database and an ID server need not be transferred toeach and every one of the accounts such as the conversion server and therouter. Only the information associated with data packets that would beprocessed or handled by that particular server would be required at theconversion server, router, for example.

Referring now to FIG. 29 there is illustrated a flow chart depicting theoperation of entering a profile. The program is initiated at a block2902 and then proceeds to a block 2904 to enter the profile, thistypically performed by a user. It could be that, additionally, a profilethat is received in the form of a filled out “form” that is provided bysome input device from a non-system user. That is, for example, orderinga product from a system node in a transaction. If the profile alreadyexists, as determined by a decision block 2906, then the program willflow to a function block 2910 to use an existing ID. However, if the IDdoes not presently exist, the program will flow along a “N” path to afunction block 2912 wherein a time stamp will be applied and then tofunction block 2914 where a sequence number will be assigned. Typically,if this particular device is creating new packets, a different sequencenumber will be attached to the various time stamp in a predeterminedsequence. However, this could be a random sequence. The program thenflows to a function block 2916 to store the ID and then to a decisionblock 2918 to determine if more profiles are to be entered. This is alsothe destination of the function block 2910. If more are required, thedecision block 2918 will flow back to the input of function block 2904and, if not, the program will flow to an End Block 2920.

Referring now to FIG. 30, there is illustrated a diagrammatic view fordefining a single ID in an ID packet. This ID is associated with theprofile for a butterfly catheter. This typically will be the item ID.There are provided, for example, six fields, the first associated withwhether it is a permanent or a joiner ID, defined by a “P” or a “J,” asecond field associated with whether it is a profile, which is indicatedby “P,” an item type defining what type the item is, indicated by a wordas a user would input it, a fourth field associated with the actualitem, i.e., that it is a butterfly catheter (the lowest classification),a fifth field for the overall type of ID packet, this being an “ID”packet, indicated by an “I,” indicated by “C” or a “V,” respectively,and a sixth field associated with the type of ID it is, an IndividualID, “I” or a Group ID “G.”

In the first profile input, the user indicates it as being a permanentID, a profile and types out the word “catheter” for the item type, andtypes and the word “butterfly” of the item that it is associated with anID, “J,” and that it is an item ID indicated by an “I.” The term“catheter” is associated with an alpha letter “C” and the word butterflyis associated with the letter “B.” When this is first created, the IDthat is generated is “PPCBITS/S.” The second item that is entered isidentical to the first one in that the user indicated this as being abutterfly catheter. The system will recognize all of the first three andlast two classifiers as being identical to others in the system and itwill also recognize that the term “butterfly” as identical to a previousone that was entered. This type of search during the classificationoperation is performed by actually looking at the database in thenon-coded column for the particular word in the field. This essentiallylooks at the spelling of the word. Since the spelling is the same as aprevious one and the first three and last two fields are the same, thenthis will be identical to an ID packet that exists and a new ID packetneed not be created. However, suppose a situation occurred where theuser misspelled the term “butterfly” as “butterfly.” In this situation,the database search would not turn up this misspelling (this is assumedthat the system does not have some type of spell check to allowadaptability to this type of situation) which basically determines thisas a new item in the database. As such, a new alpha character will beassociated with the item field, i.e., the fourth field, which is thealpha character “L” associated with the time stamp and this willcomprise a new row in the database. For the last example, suppose thatthe item that is to be classified as a butterfly catheter with thecorrect spelling, but that the fifth field is a pulmonary description.In this event, this will be a different ID and may actually result in adifferent alpha character for the fourth field associated with the item.As illustrated, this can be assigned as an alpha character “P,” whichmay be different, but it uniquely identifies this as a different itemassociated with a pulmonary catheter. However, it is the time stamp thatmakes it unique even if the same character is used.

Referring now to FIG. 31, there is illustrated a diagram of a system forlayering data packets received from different systems that arepotentially “non-like” systems. There are illustrated three systems, asystem 3102, a system 3104 and a system 3106, labeled system “A,” “B”and “C,” respectively. Each of these systems operates in a differentenvironment and may actually have a different database structure. Forexample, one might utilize an Oracle database with a specific andclearly defined database structure and another system might utilize adifferent database structure. Each of these database structures is anindependent structure with possibly separate methods for identifyingvendors and the such, i.e., there can actually be a different vendornumber in each system for the same vendor or a different product numberfor a common product. However, in the overall system utilizing the IDpackets, there can only be one common ID for a packet associated withany vendor or item. For example, if a field were present for an employeenumber associated with an employee, a field present for the days workedand a field present for the days out of the office, each of theseparticular types of data would be reflected in a different format ineach database. Therefore, a specific employee number from one databasewould have to be converted into an ID packet format for the mastersystem such that both systems employee number could be recognized,categorized and analyzed, or transferred from one system to the other.

The manner for converting data and information in one database to themaster system is provided by the extensions referred to hereinabove as“Extents,” that provide a software program for retrieving informationfrom the non-master database and converting it to ID packets from themaster system. System 3102 has associated therewith an Extent 3108,system 3104 has an Extent 3110 associated therewith and system 3106 hasan Extent 3112 associated therewith. Each of the Extents 3108 isoperable to retrieve the data and forward it to a conversion server 3114as ID packets. The interface connection between the Extents 3108-3112and the conversion server 3114 are illustrated as separate connections,but they are actually transferred through the network. Additionally,there could be multiple inputs to the conversion server from differentnetworks.

Each of the Extents is interfaced to an ID server 3116, which ID server3116, which ID server 3116 is operable to “push” IDS for various itemsand the such to each of the associated Extents. For example, if system3102 had associated therewith database information that was to beconverted over to an ID packet out of the ID packets associatedtherewith would be stored in the Extent 3108. When initially set up,system 3102 would recognize for example, that each employee in itsdatabase required a separate ID packet to uniquely identify thatemployee. These would be set up by the ID server 3116 and pushed to theappropriate Extent 3108. Therefore, whenever system 3102 transferred anemployee number as part of a data transfer to the conversion server 3114or any other account server on the system, it would be processed throughthe Extent 3108 and the appropriate ID packet generated, i.e., extractedfrom the associated ID packet table of the Extent 3108, and thenforwarded to the conversion server 3114. In the example of FIG. 31, theconversion server 3114 is illustrated as the destination of theinformation for the purpose of layering, as will be describedhereinbelow. However, it should be understood that all of the data willfirst go to a router and then to the appropriate account server, ifnecessary. The illustration of FIG. 31 is simplified for this example.

When data from system A is received for a particular conversionoperation, it is stored in a database 3118 in a first location 3120. Allthe data from system 3104 is associated with a location 3122 and all theinformation from system 3106 is associated with a location 3124 indatabase 3118. This information is layered, such that common ID packettypes, such as employee numbers, are arranged in a predetermined format.This is illustrated in a Table 3126, which is organized to illustratefour ID packets, IDP1, IDP2, IDP3 and IDP4. IDP1 may be employee numberswhich are arranged in three locations, such that they all are in acommon column. It should be understood that each of the IDPs can bedifferent for employee numbers, i.e., each employee has a separatedistinct ID packet. As such, if system 3102 and system 3106 both had thesame employee in their database, they would have a common ID packetassociated with the ID server 3116, this being set up initially. It canbe seen, therefore, that the layering system allows a transaction or ananalysis to pull data from non-like systems, convert it to like data inan organized structure and dispose it in a common table that will allowanalysis thereof. An example of this will be described hereinbelow.

Referring now to FIG. 32, there is illustrated a diagrammatic view ofthe transaction system for utilizing ID packets to converse between twosystems through a master space. As described hereinabove, this masterspace includes the router, the network mesh, the core servers, the IDserver, etc. that are required to process data packets. In FIG. 32, thissystem is illustrated with a block 3202 that defines the master datasystem. The master data system is essentially a system that receives,routes and operates on data packets to perform processes, etc. Asdescribed hereinabove, each of these ID packets constitutes a pointer tosome process associated with traversal of information through the masterdata system 3202 from an origination point outside the system to adestination point outside the system through the master data system 3202or to a point within the master data system for processing thereof. Thisprocessing system is referred to with a block 3204 which is operablethat is also provided a master ID server 3206 that contains the IDpackets that are operable with the system, these referred to as internalID packets. These are differentiated from external ID packets for anexternal system, which is not disclosed herein.

There is provided an external system 3208 that interfaces with themaster data system 3202 via a conversion block 3310, system 3308 havinga local database 3312 that is associated with its native databaselanguage or structure. Similarly, there is provided a second system 3314that is interfaced with the master data system through a conversionblock 3316 and has associated therewith a native database 3318. In orderfor system 3308 to interface with system 3314, it is necessary toextract data, convert it to an ID packet that is compatible with amaster data system 3202, process it therein and then route it to system3314 through the conversion block 3316, at which time it arrives atsystem 3314 in a structure similar to the native database 3318. Thisallows non-like systems to communicate with each other as long as theyhave a common space to go through.

In order to operate in this manner, there must be some type ofconversion to the master data space. This is not necessarily defined bythe system itself, but, rather, the master data system 3202 through itsID server 3206 defines the manner by which each system will communicatetherethrough. As such, this is a push operation with the definition. Notonly are the parameters of the definition assigned, but the actual IDpacket that is communicating therebetween. For example, there mayactually be a common item, such as a catheter, that exists in bothdatabases. By having this information determined by the master ID server3206, an ID packet can be generated in the master ID server 3206 andassociated with the same items in the two different databases 3312 and3218. As such, it is important that the master ID server be able toidentify the ID packet and associate it with the same item in twodifferent databases such that, when pushing the ID packet to one of thesystems, it also pushes the associated relationship to information inthe database 3312 or 3318. For example, an employee number in database3312 has a certain format and value that is set up in the master IDserver 3206 as being related to a specific ID packet. When the ID packetis transferred to the conversion block 3310, it is associated with itsvalue in the database 3312. Therefore, whenever the value in database3312 is sent to the conversion block 3310, this value acts as a pointerand the appropriate ID packet can then be forwarded to the master datasystem 3202.

Referring now to FIG. 33, there is illustrated an alternate embodimentof the embodiment of FIG. 32. In this system, there are provided twosystems, a system 3302 and a system 3304. System 3302 has associatedtherewith a master data system 3306 and a master ID server 3308. System3304 has associated therewith a master data system 3310 and a master IDserver 3312. There is provided one external system, system 3314associated with system 3302 in a conversion block 3316 disposed betweensystem 3314 and master data system 3306. There is associated in a localdatabase 3318 with system 3314. ID server 3308 is internal to the masterdata system 3306. Therefore, whenever system 3314, which is part ofsystem 3302, communicates with master data system 3306, it will useinternal ID packets associated with the ID server 3308, as describedhereinabove. However, when conversing with master data system 3310, theID packets are different, they are those associated with ID server 3312,these being external to system 3302. Therefore, master data system 3306has stored in ID server 3308 external ID packets associated with theexternal side of the system, i.e., all other systems that are externalthereto.

System 3304 has associated therewith an external system node 3320, whichcommunicates with master data system 3310 through a conversion block3322 and also has associated therewith a local database 3324.

When a transaction occurs which requires information to be transmittedfrom system 3314 over to system 3320, a data packet will be generatedfor information in the local database 3318. For example, ifa simpletransaction such as an employee number was required to be transferred tosystem 3320 for operations thereon as a portion of a process, theemployee number would be extracted from D database 3318 with theconversion block 3316, as part of the overall transaction. This employeenumber would be converted to an internal ID packet associated withsystem 3302. At the master data system 3306, information in the IDserver 3308 would be utilized to determine the external data packet tobe transferred to master data system 3310. As described hereinabove, itcould actually be the ID packet associated with the employee number thatresides in ID server 3312. Alternatively, it could be a joiner ID packetwhich is a negotiated ID packet between the two systems, such that theactual ID packet associated with the employee number in either of thesystems 3302 or 3304 is not known to the other.

Once the ID packet, with a joiner ID packet, are transferred from masterdata system 3306 to master data system 3310, it is the processed inaccordance with the transaction and transferred to the conversion block3322 as the appropriate ID packet for that employee number. This is thenconverted to the format of database 3324 and processed by system 3320.

Referring now to FIG. 34, there is illustrated a diagrammatic view of anexample of a transaction. In this transaction, it is desirable to haveinformation about employees as to the number of days they worked and thenumber of days they did not work. This information is analyzed in themaster data system 3202. Therefore, the first thing that must beperformed is a conversion from the employee number to a data packet, thedays in information to a data packet and the days out information to adata packet. The employee number has previously been determined througha profiling operation to be defined as a unique ID packet. Therefore, arelational database can be utilized to pull the employee number from adatabase that is associated with the conversion block. The days ininformation can also be a unique data packet. For example, there couldbe a unique data packet for the days in information for values from1-364, each different. Alternatively, there can be a single ID packetassociated with the days in field and then a collateral or ancillaryvalue data field that could be transmitted after the ID packet, asdescribed hereinabove with respect to variable length data. This is thesame situation with the days out field.

The information is illustrated in a table 3402 in the native database.This is converted to a packetized value for a given row in a transactionpacket. The first ID packet, IDPKT P, 3404 is generated to indicate theprocess that is being carried out, i.e., employee information regardingthe days in and days out as being transferred to the master data system3202 for the purpose of evaluating information in a particular process.This is followed by an ID packet 3406 labeled “IDPKT EM” for theemployee number. Followed by that would be an ID packet 3408 for thedays in. This is followed by an ID packet 3412 for the days outinformation. At the End of the information is provided a terminationdata packet 3418. This represents a single row of information beingtransferred, although it should be understood that the initiation of theprocess could constitute multiple rows and information in the form of anID packet could be forwarded as a part of the transaction packetindicating the block size of the data that would be sent. This is then“stacked” in a stack 3420 such that it is stacked in a processing stringas opposed to an organized data structure of columns and rows. Since thedata is comprised of data packets, it is possible to place the data insuch an organization.

Referring now to FIG. 34A, there is illustrated a diagrammatic view ofhow the database is populated with ID packets. It can be seen that thereare two columns, one for employee and one for an ID packet thatrepresents data in and data out. It can be seen that unlike data isstored in the second column, i.e., that the information regarding daysin is different than that regarding days out in that it would normallybe contained within different columns of a database. This facilitatesthe processing operation. Therefore, by utilizing ID packets, the IDpackets can be assembled in single columns representing different data.Further, they can be assembled in the column in the sequence in whichinformation is to be processed in the later analysis routine.

Core ID Generator

Referring now to FIG. 35, there is illustrated a diagrammatic view ofthe operation of generating ID packets in the system. There isillustrated a network 3502 which has associated therewith a generic hostnode 3504 and a generic account 3506. These two nodes are merely nodesthat are disposed on the systems that require knowledge of various IDpackets in the system in order to process various portions of atransaction. The ID packets are created in an ID packet generator block3508, this interfaced to the network 3502. The ID packet generator block3508 is actually a program that can be implemented at any node on thesystem. It is, as such, a functional element. It interfaces with an IDpacket database 3510, which can also be disposed locally with the IDpacket generator 3508 or at another location on the network. It is onlynoted that the ID packet database 3510 is associated with thefunctionality in the ID packet generator 3508, regardless of where thesystem that it resides.

Referring now to FIG. 36, there is illustrated a more detailed diagramof the operation of the ID packet generator. The ID packet generator3508 is generally initiated with the input of a data input device 3602,this allowing an individual or corporation to input information to thesystem in the form of a profile in a predetermined format. As will bedescribed hereinbelow, this profile is predetermined and sets variousfields that are to be filled in by the individual inputting the data.This information is input to a profiler block 3604 which takes theinformation received from the data input device 3602 in the particularfields and associates it with a given profile format. There is typicallya profile number associated with the profile, such that the fields canbe input in a finite way.

The profiler 3604, as will be described hereinbelow, performs theclassification associated with the creation of an ID packet. At eachnode in the ID packet generator 3508, there is provided predeterminedinformation about the ID packet. This typically is information about thecorporation that owns the node associated with the ID packet generator3508 and the actual identification of the node at which the ID packetgenerator 3508 resides. Therefore, there will be provided a core IDgenerator 3606 that has the owner of the system, i.e., the corporationthat is doing the ID packet generation operation, selected from a coreID database 3608. This will provide the first portion of the ID packet,this being the core ID. There will also be a predetermined device IDgenerated by device ID generator 3610, selected from a device IDdatabase 3609. Although not illustrated, this would actually begenerated in another classification operation, which is not describedherein, but which is similar to that associated to the item ID that willbe described herein.

In order to determine the item ID, this being the purpose for creatingan ID packet and filling in the profile, an item ID generator 3612 isprovided. As described hereinabove, the item ID generator 3612 isoperable to generate the item ID, which is associated with a group IDand an individual ID. The group ID will typically be predeterminedalthough it does not have to be, and then the individual ID must bedetermined as to its classification and as to its uniqueness. Theuniqueness, as set forth hereinabove, is that associated with the timestamp, provided by block 3614 and a sequence, provided by sequencegenerator 3616. A classifier 3618 is provided that operates inconjunction with the profiler block 3604 to determine the classificationof the item. This classification, in conjunction with the sequence andthe time stamp, are combined together to provide an individual ID. Theresulting item ID, as also described hereinabove, comprises a group IDand an individual ID.

Once the item ID has been generated, then the ID packet is generated bycombining the item ID, core ID and device ID together with a summingblock 3618. This is then stored in the database 3510 in conjunction withthe profile information. Although the classifier 3618 can utilize theinformation in the input information provided to the profile block 3604,all this information may not be part of the classification scheme. Assuch, all of the information utilized to classify the item ID and theadditional information not necessarily utilized therefor will be storedin a database in association with the created ID packet. This isillustrated by a table 3624 which is comprised of a profile number,associated with the profile that created the overall profile, profileinformation in a column 3626 and the associated ID packet in a column3628. This is the information that typically will be transferred withthe ID packet, i.e., when another node receives an ID packet andassociated information, it could actually utilize the profileinformation associated therewith in the column 3626 to create a new IDpacket, since this constitutes the bulk of the information.Additionally, as will be described hereinbelow, information that was notclassified would actually have links to other ID packets. For example,if the ID packet were utilized to classify a butterfly catheter, it maybe that the classification system, at its lowest level, will onlyclassify butterfly catheters. Additional information could be providedas to the color of the catheter. For example, if the butterfly catheterwere red, thin, or the such, there would be provided a link to all IDpackets having the word “red” disposed therein as any portion of theprofile. All information in the profile is linked and not just thenon-classified portion. In order to search the ID packet database, itwould only be necessary to utilize the classification system to “drilldown” to all ID packets associated with butterfly catheters to theclassification preamble in the item ID (typically the individual ID inthe item ID), and then filter this search with the links to the word“red.” This will be described in more detail hereinbelow.

Once the ID packets have been generated, the second portion of theoperation of the ID packet generator 3508 is the propagation operation.In this operation, various programs, referred to as “Extents,” areinitiated by a propagation engine 3630 to extract the appropriate Extentpropagation algorithm from a storage area 3632 which will define howinformation is propagated from the database 3510 to various nodes in thenetwork, it being understood that the node on which the ID packetgenerator resides could actually be a node to which ID packets aretransferred. This propagation operation is performed via a schedulingoperation or a triggering operation, as noted by block 3634. Therefore,there could be some external trigger or internal trigger that results inthe propagation of information or could just be a scheduling operation.Once the trigger/scheduler has indicated that a particular Extent shouldbe performed, i.e., there is a predetermined process initiated orlaunched, then select ID packets are propagated to the appropriate node.For example, it may be that a particular transaction requires certainportions of the ID packet database to reside at a conversion server andat the host node. When these ID packets are created, a propagationExtent will indicate that all data associated with a particular profile,for example, to be transferred to select ones of the nodes. Further, aswill be described hereinbelow, there are process ID packets that can begenerated and propagated in a similar manner. It is noted that not allID packets are required at each node nor are all Extents (noting thatthe Extents are actually ID packet or groups of ID packets) required ateach node. Therefore, this propagating Extent at block 3632 will definewhere the ID packets are transferred, this being for the purpose ofcarrying out the transaction at each respective node in theprocess/transaction path.

Referring now to FIG. 37, there is illustrated a flow chart for creatinga profile. The program is initiated at a function block 3702 and thenproceeds to a function block 3704 to pull up the select profile forinterface with a user. Once the user has interfaced the profile, data isinput to the profile, as indicated by a function block 3706, thisinformation being input to select fields. Once the select fields havebeen filled in and the profile has been accepted, the program will flowto a function block 3708 wherein the device ID and the core ID will befetched to provide the first two portions of the ID packet. The programwill then flow to a function block 3710 to generate the classificationportion of the ID packet. This may involve generating the classificationportion for both the group ID and the individual ID. However, if onlythe item ID is to be classified, then only the classification portion ofthe individual ID of the item ID will be generated in the block 3710.The program then flows to a function block 3712 wherein the time stampand sequence number are applied, rendering this ID packet as to theindividual ID or the group ID or both. The program then flows to afunction block 3714 to create the ID packet by assembling the device ID,core ID and item ID together. The program then flows to a function block3716 to store the ID packet and the associated profile information inthe database and initial copy in the block 3718.

The resulting data packet is illustrated in FIG. 37 a in that thegenerated ID packet in the first field 3720 is associated with two typesof information—standard information in a field 3722 and nonstandardinformation in a field 3724. Standard information is information that isgenerated for all items of the type profile being created. Of thestandard information in field 3722, there are provided two regions,classification information which is required to form the preamble in theindividual ID or group ID and nonclassification information which isinformation such as the color “red” associated with a butterfly catheterin the example described hereinabove that is not subject toclassification, i.e., that is not required for the generation of theclassification in the block 3710. There is also provided nonstandardinformation which can be stored in association with the ID packet infield 3720. This information constitutes items that only exist withrespect to a creator system and may not be information that is definedor desired on a global basis. Effectively, this is similar to allowing acreator to add notes to a profile.

Referring now to FIG. 38, there is illustrated a flow chart for theoperation of creating the ID packet, which is initiated at a block 3802and then proceeds to a block 3804 to generate the item ID. It combinesthe classification generated in the block 3710 with the time stamp andsequence number generated in the block 3712. Once the item ID isgenerated, then the program proceeds to a function block 3806 to linkattributes of the item, these creating an input in the profilingoperation in block 3706. These attributes are linked to an entry in anattribute table. This attribute table links such things as “red” to allID packets in the system with that attribute. Even though an attributeis utilized in the classification operation, this attribute is stilllinked to an attribute table. For example, there might be an attributethat is entered into the profile that is associated with classificationand some that are not associated with classification. For example, abutterfly catheter may have a color associated therewith, such as red,yellow or green. This is not considered important enough to constitute aclassifier. Paint, on the other hand may utilize this term “red” as aclassifier. Therefore, the term “red” for both the butterfly catheterand the paint would be linked to the same attribute table. One couldthen search all item IDS that have associated therewith the color red,regardless of what they were. Once the attribute has been linked, theprogram then flows to a function block 3808 to assemble the core, deviceand item ID in the block 3714. The program then flows to a Return block3810.

Referring now to FIG. 39, there illustrated a diagrammatic view of thescreen that is presented to the user. There is provided a primary screen3902 which has a plurality of fields associated therewith. The examplein FIG. 39 is associated with inputting information regarding a newbirth in a hospital. Each child is considered to be an item that hasassociated therewith a unique ID packet. Of course, the core ID would bethat of the hospital, the device ID would be that of the actual devicegenerated behind the packet, i.e., the unique device ID of the nodegenerating the profile, and the item ID that is unique to the child. Itshould be understood that the group ID in the item ID would probably bethe same for all children. The individual ID, on the other hand, wouldbe unique to that particular child. Interestingly enough, there may betwo children that have the same exact classifier, but that have adifferent time stamp and sequence number, i.e., they would therefore beunique. The difference is in the profile information that is associatedwith that particular individual. For example, there are provided aplurality of fields, one field 3904 for the name, a field 3906 for thegender, a field 3908 for the address, a field 3910 for the weight, afield 3912 for the date of birth, a field 3914 for the length, a field3916 for parental data, a field 3918 for an internal reference number,this being an example of the nonstandard information that will beassociated with a profile, a field 3920 for the doctor and a field 3922for image links. Note that these image links would be non-standardinformation that would be links to images in a system and these linkswould not necessarily be desired by other systems. The primary profile3902 has associated therewith a profile number 3924 that is associatedwith this profile in the system.

When this profile is initially created, there is provided a very longstandard information profile 3926 that defines the standard informationthat must be associated with the child. For example, there is provided adevice ID field 3928, a core ID field 3930 and a classification field3932. This predetermines what the device ID and the core ID will be andalso predetermines all or a portion of the classifiers associated withthe item ID and/or the group ID. There may also be a title field 3934for the title of the profile. Therefore, this standard profile template3926 is utilized to create substantially all of the information neededto create the ID packet. In fact, if the classification is the same forall children, then the information in the profile screen 3902 would benonclassification information that would be considered standard.information to retrieve (although some of this may be nonstandardinformation such as the internal reference number in the field 3918.)However, typically, there will be one or two classifiers that will notbe standard for every child associated with the individual ID portion ofthe item ID. For example, it may be that there is a classifier for theethnicity of the child or eye color.

It can be seen that all of the fields in the profile 3902 are definedfields and the information therein will be linked to the attributetable. For example, although gender in field 3906 may not be aclassifier, it will be linked to the attribute table. Therefore, all IDpackets having a profile with the term “female” associated therewith canbe searched through the attribute table.

Referring now to FIG. 40, there is illustrated a flow chart depictingthe operation of propagating the ID packets, once created, to selectones of the network nodes or other locations in the system. The programis initiated at a block 4002 and then proceeds to a decision block 4004to determine if a trigger operation has been received. This triggeroperation can be an external trigger or it could be a schedulingoperation determined by the scheduler. The program, once determining atrigger is present, proceeds to a function block 4006 to run thepropagate Extent for the triggered item. As noted hereinabove, eachprocessor transaction on the system may require a certain group orgroups of ID packets to be associated with that transaction. These IDpackets must reside on the appropriate node in the system to which thetransaction will be relayed during the process. It is thereforeimportant that the appropriate ID packets associated with either itemIDS or process IDS or even network address IDS to be resident at thenode once the transaction packet, in its original form or modified form,is transferred thereto. As such, this propagation Extent will be run forparticular processes or groups of processes or vanous transactions.

Once the propagation Extent has been run, this propagation Extent willpull data from the database 3510, as indicated by a function block 4008.The program will then flow to a function block 4010 to create atransaction packet, which transaction packet is operable, in accordancewith the operation of the Extent, to transfer ID packets to anotherlocation on the network. It is very similar to the situation describedhereinabove wherein data is transmitted to a destination node. In thissituation, the destination node is the node to which ID packets are tobe transferred, this being data. It should be understood that, not onlyare ID packets transmitted, but the profile information associated withan ID packet is transmitted. As such, an entire row of the database 3510will be transferred. And, therefore, it should be considered to be data.Once the transaction packet has been created, it is transmitted to thedestination node, as indicated by function block 4012 and then theprogram proceeds to a function block 4014 to perform an acknowledgmentoperation and determine if the transaction packet has been received.This will be described hereinbelow. If so, the program will flow on the“Y” path to a function block 4016 to set a flag indicating that the datain the database, i.e., the updated ID packets or newly created IDpackets, have been appropriately transmitted to the destination one ofthe nodes at which the ID packets must be stored. Once the flag is set,the program will flow to a Return block 4018. If acknowledgment has notbeen received, then the program will flow along the “N” path fromdecision block 4014 to a function block 4020 to run a propagate Extentindicating that there has been a failure of the propagation algorithm.This may result in a page or E-mail being sent to a technician orgeneration of a failure log or report. This will then be handed off toeither an individual or another process to service. The program willthen flow from function block 4020 to an End block 4022.

Referring now to FIG. 41, there is illustrated a flow chart depictingthe operation of the acknowledgment operation in decision block 4014.This is initiated at a block 4102 and then proceeds to a decision block4104 to determine if an acknowledgment has been received. If so, theprogram will flow along the “y” path to the Return block 4018 throughthe function block 4016 to set the flag (not shown). If, however, theacknowledgment has not been received the program will flow to a decisionblock 4106 to determine if a time out operation has occurred. Theprogram will loop back around to the input of decision block 4104 untilthe time out has occurred, at which time the program will flow to afunction block 4108 to transmit a look-up ping to each of thedestination nodes, i.e., this being a “push” operation wherein the IDserver that generated the ID packets and propagated the ID packets willdetermine whether they have been received by the destination node. Eachdestination node has a table that is created at the ID server thatrepresents the ID packets that are disposed therein and the associatedprofile information. There is also provided a column indicating a flagrepresenting the successful transfer or lack thereof. Therefore, eachentry must have a “ping” sent to the destination node. This pingbasically defines the address at the destination location, this beingknown at the ID server, which will determine if information has beenreceived thereat. The program will flow to a decision block 4110 todetermine if a return acknowledgment has been received indicating thatthe ID packet in fact resides at the ping address which is achieved bysending the principal address back to the ID server. If anacknowledgment is received, the program flows to a Return block 4112,substantially that equal to Return block 4018 indicating that the flagis set in the table and, if not acknowledged, the program will flow to adecision block 4112 to 4114 to determine if there is a transmission timeout. If so, the program will flow along a “Y” path to a failure block4116 and, if not timed out, the program will flow along an “N” path to aretransmit 4118 to retransmit the ping. Once retransmitted, the programwill flow back to the end of the function block 4108.

When the ID packet is propagated, it is facilitated in two ways. First,the ID packet with profile information is sent. This would result in theID packet constituting the primary “ping key.” All that is necessary tosend is the ID packet in order to determine the address at thedestination. This destination address is then returned with the IDpacket and stored at the ID server. In the second case, only the profileinformation is propagated. This requires a field in the profile to bedefined as the ping key. For example, when sending information to a hostsystem, it may not be desirable for the ID packets to be disseminated.In this situation only profile information is sent. For a vendorprofile, the vendor name (or number) is the ping key, as defined whenthe profile is set up. The ID server transmits the profile informationto the extent running on the host, which then has knowledge of whichnative tables in the host the information must be routed/linked to. Oncetransferred, then the destination address of the ping key (vendor namein this example) is returned for storage at the ID server. Since the IDserver has knowledge of all the destination addresses (there could bemore than one for each ID Packet), this facilitates system clean up. Forexample, if a vendor needed to be changed ro deleted, then the ID serveras a central repository could repropagate the changes to all of thelinked to destination addresses.

Referring now to FIG. 42, there is illustrated a flow chart for thelook-up ping operation, initiated at a block 4202. The program will thenflow to a function block 4204 to send a request to the router, it beingnoted that the router is the first place that the ping will be sent. Inthe preferred embodiment, the request to determine if an address hasbeen sent is handled by the router. The request is sent to the routerand then the router communicates to the destination node, as indicatedby a function block 4206. The function block makes a determination as towhether the transmitted ID packet and its profile information resides atthe destination node. This is indicated by a decision block 4208. If ithas been sent there, the program will flow along a “Y” path to a block4210 to send an acknowledgment signal back to the ID server and, if not,a nonacknowledgment signal will be sent back, as indicated by a functionblock 4212. The program will then return, as indicated by a block 4214.

Referring now to FIG. 43, there is illustrated a flow chart depictingthe operation of defining the profile. This is an operation wherein theoverall templates for the profile are defined. This program is initiatedat a block 4302 and then proceeds to a function block 4304 to set thecore ID and then to a function block 4306 to set the device ID. Theprogram then flows to a decision block 4308 to determine if the group IDand the item ID is fixed. If not, the program will flow to a functionblock 4310 to set the field parameters for the group. This is anoperation wherein certain field parameters will be defined for thegroups and, once filled in, they will set the classifiers for the groupID. If the group is fixed, the program will flow along a “Y” path to afunction block 4312 wherein the group ID is set as a fixed item.

Once the group has been set, either as a fixed group ID or as asubstantially fixed group ID (the group can either be a set item as toboth the time stamp and the sequence or, if a parameter is to be set,then a time stamp and sequence would be added after the group IDclassifier has been defined), the program will flow to a decision block4314 to determine if the individual ID is fixed. As noted hereinabove,there may be situations wherein the item ID is always a set ID in termsof the classifiers. If the individual ID is fixed, the program will flowalong an “N” path to a function block 4316 where the field parametersfor the individual ID are set. These, as described hereinabove, describethe classifiers for the individual ID. If the classifiers for the fieldare set, the program will flow along the “y” path to a function block4318 to set the fields for the individual ID in the classifiers. Theprogram will then flow to a function block 4320, it being noted that,during the set up of the profile, the time stamp and sequence willtypically be added for at least the individual ID portion of item ID.

At the function block 4320, additional attribute fields will be definedwhich are not a portion of the classification operation. Theseattributes will then be linked to the attribute table, as indicated by afunction block 4322, the attributes linked being both the onesassociated with the classification and the ones associated with thenonclassification operation. The program will then flow to a decisionblock 4324 wherein a decision will be made as to whether the content islimited, i.e., if a color were the type of field indicated by functionblocks 4320 and 4322, i.e., the title of the field, then the content maybe limited to a pull down menu of the multiple colors. If so, theprogram will flow to a function block 4326 wherein the available entryfor that particular field will be noted. If not, the program will flowalong an “N” path to a decision block 4328 to determine if the field hasbeen validated. Decision block 4328 indicates the field as being an“open” field, wherein the program will flow along the “N” path to afunction block 4330 or whether the field is required to be validated, asindicated by the flow along a “Y” path to a function block 4332 whereina “valid” flag will be set. The validation operation is one that linksthe field to the attribute table, and will define the contents thereofas linkable when populated. This facilitates searching of the field,when the ID packet is created. For example, if an address field such as“Street” is defined, this would be linked to the street attribute in theattribute table. When this is filled in upon creating the ID Packet,then the actual street name will be linked to the dictionary. If it isopen, then this field is not linked to the attribute table or thecontents linked to the dictionary. Once the field is defined as an openfield or a field that must be validated, the program will flow to adecision block 4334 to determine if additional fields are to be added.Once all fields have been added, the program will flow to a “Done” block4336.

In the operation of defining the attribute field type, i.e., the titleof the field, this will link the field to the attribute table. This willbe done before information is added thereto. As such, when informationis added in a profile and the profile is accepted and the ID packetsgenerated, the information defined in the profile that is associatedwith the ID packet will contain all the field names and the content ofthose fields. The links to the profile number are already preset, suchthat a new link need not be made. Therefore, when a new profile isgenerated, the unique address of that profile is the ID packet, sincethe ID packet is a unique value in and of itself. As soon as this IDpacket is generated, it will immediately link to each of the field typesin the attribute table. When content is added, a procedure must befollowed wherein a dictionary is accessed to determine if the word is acorrect spelling and then a decision made as to what the word isassociated with. For example, it might be that a word is entered into afield having multiple meanings. This would be presented to the user oncethe content was entered such that the user could select the meaning ofthe term such that it will point to the correct meaning in the attributetable. This dictionary can also check for spelling mistakes, languagetranslations, etc.

Referring now to FIG. 44, there is illustrated a diagrammatic view of asystem for propagating the ID packets from one ID server to a secondsystem having an associated ID server. There is illustrated a firstsystem 4402 having an ID server 4404 associated therewith, the ID server4404 having an associated ID packet database 4406. The ID server 4404interfaces with a local network 4408 having a router 4410 associatedtherewith. The system 4402 utilizes the router 4410 to interface with agateway 4412. The gateway 4412 interfaces with a second system 4416 viaan associated router 4418. The router 4418 interfaces with a localnetwork 4420 for the system 4416. The system 4416 also has associatedtherewith its individual ID server 4422 interfaced with the localnetwork 4420, the ID server 4422 having associated therewith its own IDpacket database 4424. In operation, each of the ID servers 4404 canservice their own systems to generate ID packets therefor. Each of thesystems also has associated therewith other nodes, such as a host node4426 for system 4402 and a host node 4428 for the system 4416. When eachof the respective ID servers generates ID packets locally, they can eachdownload them to their respective hosts 4426 or 4428 or even theassociated routers 4410 and 4418. However, in some situations involvedwith transactions between two systems, it is necessary to provide IDpackets from one system to the other. This will result in, for example,the flow of ID packets from server 4404 to system 4416 for storage inthe various nodes associated therewith. Typically, the ID server 4422will receive the ID packets and then propagate these ID packets to thevarious nodes associated therewith.

Referring now to FIG. 45, there is illustrated a diagrammatic view oftransfer of an ID packet and information from one system to another.There is illustrated a first system associated with a company “A” 4502,a second company, company “B” 4504. Company A desires to send datapackets to company B. These ID packets and the associated informationsuch as the profile, the profile numbers, etc. are stored in an internaldatabase 4506 at Company A. The data is stored in a table format, asillustrated in table 4508. This table will be organized in rows andcolumns, each row comprising all the information necessary for transfer,this being an ID packet, and all of the profile information associatedtherewith.

When information is transmitted from one company to another, it can betransmitted as the unique ID packet wherein the ID packet provides a“pointer” or address for the information. However, in certainsituations, the particular ID packet associated with the company and foruse internal to the company may not be of such a nature that the companywould desire to transmit the information. For example, the core IDportion of the ID packet is unique to that company and this informationmay not be something that the company would want to be broadcast.Therefore, they create a new ID packet value as a joiner ID packet thatis transmitted to the other company. Typically, this joiner ID packetwill have a different value. It may in fact have the same preamble inthe group ID and individual ID for any of the core ID, device ID or itemIDS. However, the time stamp could be different. As such, this would bea different value. The reason for maintaining the preamble portion ofthe group ID and/or the individual ID for any of the three parts of theID packet would be to maintain the classification system associated withall of the information in the ID packet. Although the classificationinformation is identical or substantially identical, the time stamp andsequence number would be different, thus rendering the ID packet adifferent value. This function is facilitated by joiner conversion block4510. When the joiner table has been created with the joiner conversionblock 4510, this will provide a second cross-reference table which willbe basically a “pointer” to the ID packet and the table 4508. Theinternal database 4506 will maintain this joiner ID. Basically, it is across-reference table such that information can be transmitted back andforth with different unique ID codes that will only be recognizable bythe internal database 4506. One use of the joiner ID packet is toterminate the connection by merely erasing the joiner ID packet suchthat it will not be recognized, this termination not affecting thedatabase 4508.

When the information has been appropriately converted or not converted,it is transmitted to the system 4504 and input to an external database4512 at the system 4504. This external database stores the external datareceived from external systems, this being one or more systems, in atable 4514, which table organizes the information in the form ofthe IDpacket originally generated from the transmitting system (the ExternalID Packet) and the associated profile information, it being rememberedthat this External ID packet may be a joiner ID packet. Additionally,the system 4516 then interacts with the data to create an internal IDpacket. This internal ID packet is associated with the profileinformation for the originally received ID packet, but actuallyconstitutes a separate value. Since it has all of the informationnecessary to “classify” the data, it can go through the classificationoperation, as described hereinabove, to generate a new ID packet. Thisinternal ID packet is then associated with the originally received IDpacket and also the profile information. When it is necessary to utilizethe information in the table 4514 for internal operations at the system4504, only the internal ID packet and the associated profile informationwill be transmitted or propagated to various other systems.

When the external data is utilized, it typically can be filtered with afilter 4516, which filter 4516 will only fetch a certain amount of thedata for a particular system. This filter will filter off the ID packetsoriginally received and then transmit it to a filtered internal database4518. With the use of the filtered internal database, significantly lessinformation is downloaded. For example, when an internal database inanother system, the system 4502, transmits data, it may transmit all ofa portion of its database, i.e., such as its entire data catalogue.However, the internal side of system 4504 may not desire to have all ofthe catalogue transferred down to the various nodes. Therefore, aparticular Extent will run on the internal side of system 4504 todetermine what data in the catalogue is selected for propagation to thevarious nodes. This is the information that is stored in the filteredinternal database in the form of basically the internal ID packet andthe profile information, as set forth in a table 4520. This filteredinternal database information constitutes a database of ID packets whichthen must be propagated to the various systems through a propagate block4522, which has been described hereinabove with respect to FIG. 26. Thispropagate block is operable to then propagate information to any of thenodes in the system 4504, as indicated by a block 4524, which will thenassociate the propagated ID packets for storage in a system nodedatabase 4526 in the form of a table 4528. As noted hereinabove, thiswill be organized in the form of the internal ID packets and theassociated profile information, it being noted that this will probablynot be as large as the table 4520 in the filtered internal database4518.

When the propagate block 4522 propagates, the table 4528 will alsocontain a link to the internal address of the System B Node 4524 atwhich the ID packet is stored. This address constitutes a destinationaddress. This destination address is then reflected back to table 4520as a link and to the database 4512. This is then put in database 4512 toindicate which ID packets have been filtered. This is via theacknowledgment function, which returns both the destination address andthe underlying information. An example would be an entry such as acontact name. Note that, if system 4502 deleted an entry, the database4512 would determine if there is a destination address linked to anExternal ID packet and, if so, indicate to database 4518 and propagateblock 4522 that the item is deleted and then propagate the change. If ithad not been linked in the filter operation, then the item would bedeleted from the external side of database 4512 (or disabled).

Referring now to FIG. 46, there is illustrated a diagrammatic view ofthe operation wherein processes are created and propagated. In thisview, there is provided on a system the process server 4602 which isoperable to interface with a user interface 4604 to basically provideinputs to the process server, i.e., information necessary to define theprocess. The process server operates by assembling various logic blocksthat are stored in the database 4606 to create Extents or processes orsubprocesses which are utilized by the various nodes in the system.These are, after creation thereof, stored in a process database 4608.During generation of the processes, various ID packets are utilized,which are stored in an ID database 4610 and also routing information isstored in a routing database 4614. This routing information isinformation as to the various network addresses of all of the nodes inthe system, such that the process can be effective.

The process server interfaces with the local network 4616 which willbasically interface with an ID server 4620 having associated therewithits ID database 4622, possibly an account server 4624 having associatedtherewith a process database 4626 for its associated portion of theprocesses distributed thereto and with a router 4628, having associatedtherewith process database 4630. It should be remembered, as describedhereinabove, that all traffic on the system must go to the router firstbefore being routed to the other process nodes. It can be seen that,once the process server has determined the processes and stored them inthe process database 4608, it then determines where the processes needto be transmitted. Since the process defines a transaction frombeginning to end, i.e., from transmission of certain information from anoriginating node to a destination node, there will be multiple processesthat are carried out at one or more of the various nodes disposed in thetransaction path. Each of these processes is created as a group and thendistributed outwards.

Referring now to FIG. 47, there is illustrated a diagrammatic view ofthe logical flow of creating a process. The logical instructions for theprocess were input at a block 4702, which have been input to a processgenerator 4704. The process generator requires access to variousstandard process blocks stored at a database 4706. The process generatorwill receive the logical instructions and then assemble a process of atransaction that will define a group of processes for each Extent and agroup of Extents. This is illustrated as a plurality of sequentiallyperformed processes of 4708. Each of the process blocks has input andoutput and requires information to be associated therewith. For example,there may be a process block that defines a destination route andrequires information as to the originating node and the destination nodefor that particular process block. This will enable that process blockto generate possibly a portion of the transaction packet, extractinformation from the database or reside on a conversion server forprocessing the transaction packet at the conversion server. By utilizingprocess blocks, the assembly of the overall Extent is facilitated in amuch more expedient manner. Once all of the process blocks have beenassembled, it being remembered that these are a sequence ofinstructions, the logical flow will be to a finish block 4710 tocomplete the process assembly and then generate the code with a codegenerator block 4712. This code generation constitutes the process whichis then stored in the process database 4708 with a process number and asequence number for a particular transaction. It should be rememberedthat the process server for a given transaction will associate aplurality of Extents together such that, once a channel ID is defined,each process in the channel ID will recognize a previous process and thedata will flow through the system in accordance with this processsequence.

Referring now to FIG. 48, there is illustrated a flow chart depictingthe operation of propagating Extents, i.e., predetermined processes thatare generated by the process generator 4702, to various nodes in thesystem. The program is initiated at a block 4802 and then proceeds to ablock 4804 to determine the source and destination IDS in the process.The system will then flow to a function block 4806 to then “ping” all ofthe destination and source IDS required for this process. This isrequired to ensure that all of the destination and source IDS areactually on-line and working. The program will then flow to a decisionblock 4808 to determine if the ping operation has been successful. Ifnot, the program will default to an Error block 4810 and, if all thetests came back successful, the program would flow to a function block4812 to set a flag to that of a test mode. As will be describedhereinbelow, each process must go through an evaluation step before itgoes “live” in the overall transaction between two systems, nodes orcustomers. The program will then flow to a function block 4814 todistribute the various Extents that were created in the process to therespective ones of the nodes, it being remembered that the process iscomprised of a group of subprocesses, the subprocesses distributed tovarious nodes. The program then flows to a function block 4816 to sendsome type of test trigger to test the system. When the system isactually created, it may be that there is a final destination node thatis to receive information or an order. The order can be placed with somekind of notation that this is a test transaction, such that, when thetrigger signal is received for the test operation, all of the resourcesin the transaction path are “exercised” to determine if the transactionhas been completed in the manner which was contemplated by the originallogical instructions that were input to the process generator. It may bethat there are many addresses that are “dummy” in nature, such that thefinal destination of the process will end up at a dummy node with, forexample, a dummy facsimile, a dummy order, or the such. The program thenflows to a decision block 4818 to determine if the process has beenapproved. This could be a manual operation which evaluates thetransaction flow to determine if it has been executed correctly, i.e.,the correct order has been placed in the correct manner at thedestination or that a particular process interfaces with another systemin the correct manner. If it has not been approved, it may be that theprocess needs to be recreated, as indicated by block 4820. However, ifit is approved, the program will flow to a fimction block 4822 whereinthe process will be remapped to a live system, i.e., the flag may be setto a live mode or, in conjunction therewith, various addresses in theprocess are remapped to change some parameters thereof. The program thenflows to a function block 4824 to set the flag to “live” and then to afunction block 4826 to redistribute the subprocesses over to theassociated nodes. It should be remembered that a copy of each ofthesubprocesses and the overall process are maintained in the processdatabase 4608. The program then flows to a Done block 4828.

Referring now to FIG. 49, there is illustrated a diagrammatic view oftwo systems that interface internal thereto with ID packets. There isprovided a first system 4902 labeled SYS A and a second system 4904labeled SYS B. The first system 4902 has associated therewith a host4906, a network structure 4908, an ID server 4910 and a router 4912. Thehost 4906 has associated therewith a host database 4914. Similarly, thesystem 4904 has a host 4916, a network structure 4918, an ID server 4920and a router 4922. The host 4916 has associated therewith a database4924. The two systems 4902 and 4904 interface with each other through aninterconnection 4926 between the routers 4912 and 4922.

In some situations, there can exist two systems that have dissimilardatabases, i.e., the software utilizes a significantly differentoperating system and database generation system resulting in a differentdatabase structure. When two distinctly different databases are utilizedin two companies, it is difficult for the two companies to converse witheach other without some type of adapter therebetween. This situation isexacerbated when the two companies are merged. For example, when twocompanies become a single entity and desire to have a single commondatabase, it is necessary to convert both databases into a new databaseor to convert one database into the other database. This is not anuncommon situation. The problem exists when there are common aspects oftwo databases such as common products, common vendor IDS, etc. Forexample, there could be a common vendor between the two databases thatwas utilized for purchasing products from, or for shipping productsthereto. Both databases would have information associated with this samevendor entered into their respective database structure in asignificantly different manner, due to the dissimilarity of the databasestructures. However, even if the two database were the same, i.e., bothOracle® databases, they could have a different formats and the such forvarious fields, i.e., a different organization. The reason for this isthat a great deal of latitude is provided to the system administratorwhen creating the database in defining the format of ID fields. It maybe that one administrator for one database structure formats it withnumbers and the other system administrator formats it with textualcharacters. This presents a problem in that comparison of IDS in acommon field will not allow merging of records. As such, it is possiblewhen merging into a new database that there could actually be two newvendor IDS generated in the new database structure for a single commonvendor. As such, all links to the common vendor with two differentvendor IDS would still be separate and distinct, as they were in the twodifferent databases. In order for the two systems 4902 and 4904 to mergetogether into a single system, they would have to have a common databasestructure wherein the database 4914 and the database 4924 will mergeinto either a common separate database or one merged into the other.

Referring now to FIG. 50, there is illustrated a table depicting thedifference in the two systems and the way in which they might handlevendor IDS. In the example of FIG. 50, there is listed a vendor “ABC”that exists in both the database of SYS A and the database of SYS B. InSYS A, there is a unique vendor ID associated with vendor ABC, whichvendor ID is “123.” Also, there is a unique ID packet associatedtherewith in SYS A identified as “XXX.” This ID packet XXX, of course,is representative of a unique number that has associated therewith theconstituent parts as described hereinabove in the form of the core ID,the device ID and the item ID. This is for representative purposes only.In SYS B, the vendor ID is denoted as “567” and the ID packet is alsoprovided as being a unique value “YYY.” The reason that the vendor IDSin SYS A and SYS B are different is due to the fact that the systemadministrator formatted them for different values. It could be also thatthey were assigned vendor IDS in a sequential manner and it was the timethey were put in that defined what the vendor IDS would be. With respectto the ID packets, these are generated by each system's ID server and,therefore, would constitute a unique number. However, it could be thatthe classification portion of the ID packet, that embedded in the IDpacket, could be the same. It would be the time stamp and sequencenumber that would create the unique difference. In any event, it can beseen that the vendor IDS for the two systems are different for the samevendor and, therefore, some conversion must be performed.

Referring now to FIG. 51, there is illustrated a block diagram view ofthe merging operation of the two databases 4914 and 4924 into a singledatabase 5102. Each of the records in the databases 4914 and 4924 arecompared with a compare operation, illustrated as a block 5104, todetermine if they are the same. The vendor IDS may be different, but theunderlying information associated with that vendor ID would havesimilarities, if not being identical. For example, the name of thevendor would be the same, the address of the vendor would be the same,even the zip code of the vendor would be the same. By examining thisinformation that underlies the ID packet and is associated with thevendor IDS in the respective databases, an evaluation can be made as towhether they are the same vendor. If so, then this will provide a TRUEoutput from the comparison block 5104. Each of the databases isprocessed through a separate conversion block—5106 for SYS A and 5108for SYS B. A multiplexing block 5110 is provided for selecting eitherthe output of conversion block 5106 or the output of conversion block5108. When the comparison is TRUE, this indicates that the data in bothsystems is identical and, as such, the conversion of that information toa format compatible with the database 5102 will be performed by bothconversion blocks 5106 and 5108. For a TRUE operation, only oneconversion operation needs to be selected and this, in the presentexample, would be that associated with block 5106. However, if it isFALSE, then the multiplex block 5110 would first select the output ofconversion block 5106 for storage in database 5102 and then the outputof conversion block 5108, such that both IDS were converted. As notedhereinabove, when an ID packet is converted, this would result in a newID packet being generated and given a new vendor number for theconverted information. However, each conversion operation during themerge could be different and different parameters and aspects thereofcould be added or subtracted. Also, the new ID packet will have theunderlying profile information associated therewith.

In an alternate embodiment, illustrated in FIG. 52, information in onedatabase is merged into another database and made compatible therewith.In this operation, the data in databases 4914 and 4924 are compared witha comparison block 5202 to determine if they are substantiallyidentical, as was the case with respect to the comparison block 5104.Whenever a TRUE result occurs, this indicates that they are identicaland, as such, there is no need to convert the data from database 4914.There need only be a selection of the data from the database 4924 whichis provided by a selection block 5206. This would be stored in a mergeddatabase 5208 which is basically identical to the database 4924, albeitlarger. Whenever there is a FALSE comparison, i.e., there is no match toa record in the database 4914 and the data in the database 4924, thenthis data will be converted through a selection block 5210 and aconversion block 5212.

Although illustrated as being individually selected as records,typically all of the data in the database 4914 will be compared in asearch operation to the data in database 4924 to determine if there is amatch for that data in database 4924. If there is no match with the datain database 4924, then this data from database 4914 is converted andstored in database 5208. Database 5208 will be initialized with all ofthe data in database 4924 such that there effectively will not be anactual selection operation, although there could be such an operation.

Referring now to FIG. 53, there is illustrated a diagrammatic view ofthe comparison operation. In this example, the data underlying the IDpacket would be that associated with, for example, the name, theaddress, the zip code and the vendor ID code. This exists on an externaldatabase external to the database to which it is being merged, i.e., theinternal database. This information is input to a compare block 5302 andthis is compared with the name table in the internal database, theaddress table in the internal database and the zip code in the internaldatabase. Many other parameters could be compared. This is a function ofthe compare operation wherein a compare operation “pulls” data from theother database for the purpose of evaluating its presence in theinternal database. If it is determined that the profile data underlyingthe ID packet is identical, then a new ID packet need not be generated.However, if it is determined that this information is new, then a new IDpacket would be generated with the profile information and possibly anew vendor ID code generated in the database.

Referring now to FIG. 54, there is illustrated a flowchart depicting thecomparison operation, which is initiated at a Start block 5402 and thenproceeds to a block 5406 to pull the name from the external database andthen compare it to the name table in the function block 5908. If adecision block 5910 determines that it is a TRUE comparison, then theaddress information will be pulled from the external database andcompared to an address table, as indicated by function blocks 5912 and5914. If the comparison is TRUE, as determined by decision block 5916,the flow will then pull the zip code from the external database andcompare it to the zip code table, as indicated by function blocks 5918and 5920. If this results in a TRUE comparison, as determined by adecision block 5922, the program will flow to a function block 5924 touse the existing ID packet. However, if any of the decision blocks 5910,5916 or 5922 determine that it was not a true comparison, then theprogram will flow to a function block 5926 to create a new ID packet, asdescribed hereinabove. The program will then return via a return block5930.

Referring now to FIG. 55, there is illustrated a diagrammatic view ofthe operation of transferring information from a system, SYS A, to asystem, SYS B. This is a further explanation of the internal/externaloperation, as described hereinabove with respect to FIG. 45. When datais transferred between two systems, it can be transferred in the nativeform or it can be transferred in the form of ID packets, noting that theID packets for two systems may be different, as they were created withtwo different ID servers. In the example illustrated in FIG. 55, SYS Ahas provided therein a database represented by Table 5502. This databaseis divided into, for example, two columns, one associated with a vendornumber and one associated with a profile, such that each vendor numberhas associated therewith a profile. This vendor number could be an IDpacket. However, it could merely be the native vendor number of SYS A.When the data or information regarding vendors is transferred to SYS B,it is transferred essentially intact, i.e., with the vendor numbers thatexist in SYS A. (Note that the vendor number could be reflected as an IDpacket.) This will result in a database or table 5504 being transmittedto SYS B as external data therein, referred to as a table EXT A. ThisEXT A database or table consists of all of the vendor numbers in theprofile, as it existed in SYS A and in a database structure associatedwith SYS A.

At SYS B, there is a mapping function performed, as indicated by anarrow 5506 that maps all or a portion of the information in the table5504 to a new table 5508, which provides the vendor number in thedatabase SYS B in compliance with all the rules associated therewith. Asdescribed hereinabove with respect to FIG. 45, this may merely requirethe generation of an ID packet that is generated utilizing the profileinformation of the table 5504. However, the table 5508 also provides alink back to table 5504 in a column 5510. The profile information intable 5504 contains, in addition to the substantive information relatingto the vendor associated with a vendor number, various links and changeflags. The operation of these will be discussed hereinbelow.

Once the database has been created at a table 5510, which exists at theID server for SYS B, this information is then propagated to the variousaccount servers, as represented by tables 5512, there being three suchtables. Each of these tables 5512 represent other nodes in SYS B thatrequire information regarding the vendor numbers. These, in practice,could be other account servers that have their own ID servers associatedtherewith. They could, also, be such things as the conversion server,the router, etc. These are associated with nodes in the system thatrequire information as to vendor numbers without requiring the node toconstantly go back through the network to the main database at table5508 to determine what the underlying information would be.

Once the information in table 5508 at the ID server is propagated downto each of the nodes and the tables 5512, it is important that the IDserver be apprised of the address for each location in each of thetables that the particular vendor number is linked to. This is stored ina column 5514. Therefore, the ID server 5508 has a link to both the datain the table 5504 and to all other databases that lie below the table5514 in the hierarchal structure.

Referring now to FIG. 56, there is illustrated a simplified schematic ofhow information is propagated through the network from one ID server, asource ID server 5602, down to a plurality of lower servers. In theillustrated embodiment of FIG. 56, there are illustrated three lower IDservers, an ID server 5604, an ID server 5606 and an ID server 5608, forthree different systems, SYS B, SYS C and SYS D. The ID server 5604 hasassociated therewith two account servers 5610 and 5612 with ID server5606 having a single account server 5614 associated therewith and IDserver 5608 having two account servers 5616 and 5618 associatedtherewith.

In operation, there will be a “release” operation that allowsinformation to be transferred from one system to another. In the firstoperation, there will be a request made by one of the lower ID serversfor information, which information will then be released to that IDserver, i.e., this indicating that the data being released is a validdata. This is then transmitted down to the external side of one or moreof the servers 5604-5608. At each of the servers 5604-5608, the data isconverted to the database structure on the internal side thereof asinternal data to that ID server. This is then propagated or released ina second operation to one or more of the account servers associatedtherewith, i.e., to a lower level. Thereafter, when information ischanged, then a change or release is “pushed” from the higher level tothe lower levels and this change then propagated downward. For example,if ID server 5602 for SYS A had propagated data such as a catalogue downto one or more of the servers 5604-5608, and then desires to create achange, it must change the information at every location that it ispresently disposed at. Suppose that this information were disposed attwo or more of the account servers 5610-5618. In order to facilitatethis change, the ID server 5602 would merely have to push the change toeach of the servers to which the original information had been released.Once the lower level ID servers 5604-5608 receive the changeinformation, then they will make the corresponding change in all of theservers therebelow. The reason for this is that the ID server 5602 isaware of all locations to which data was originally released or pushedto and the ID servers 5604-5608 are aware of all the addresses of thatparticular information and can then propagate down the change to thoseservers.

The system of FIG. 56 is illustrated in a simplistic form in FIG. 56 a.In FIG. 56 a, there is illustrated a database 5630 associated with SYS AID server 5602. A particular data field or addressable location 5636 isillustrated. This is passed through a mapping function 5634 for storagein a database 5636 as an addressable information field 5638. Thisinformation in addressable field 5638 is then propagated down to each ofthree databases 5640, 5642 and 5644 at addressable locations 5646, 5648and 5650, respectively. When the change is required in the addressablelocation 5632 in the ID server 5602, this change merely needs to be“pushed” to the database 5636 into the addressable location 5638. Thisis facilitated, as described hereinabove, by pushing into the externalside and then an Extent operating to reflect this change over to the SYSB database 5636. Once the change has been stored in addressable location5638, by utilizing the links that were created in the database 5636,each of the addressable locations 5646-5650 can have a change pushedthereto. As such, there is a “one source” link to all of the informationthat exists within the network, this being that addressable location inthe database 5638. By making the change at this one source, then all ofthe data in the system can be changed.

Referring now to FIG. 57, there is illustrated a flow chart depictingthe operation wherein data is transferred from one system to theexternal side of a second system. The program is initiated at a block5702 and then proceeds to a function block 5704 wherein a transactionalrelationship is initiated. In this operation, a contact will be madefrom, for example, SYS B to SYS A requesting information. Thisinformation may be in the form of their vendor list, their productcatalogue, etc. Also, the manner by which a transaction between the twocompanies will be effected is also determined. Once the relationship hasbeen initiated, the program will flow to a decision block 5706 todetermine if data in the form of vendor numbers, product catalogues,etc., is to be downloaded. If so, the program will flow along the “Y”path to a function block 5708 to transfer the SYS data to the externalside of SYS B. At SYS B, this external data from SYS A is then mapped tothe internal side of SYS B, as indicated by a function block 5910. Theprogram then flows to decision block 5912 in order to determine if theSYS B address is to be sent to the SYS A system. This is optional. Thisis an operation wherein the actual location in SYS B on the internalside thereof can be transmitted to SYS A. This would allow, for example,SYS A to actually point to the location within SYS B at which the datawill be populated, as described hereinabove. However, in the preferredembodiment of the disclosure, the addressing is typically maintained atSYS B and SYS A and is only allowed access to the external side of SYSB. If the option is selected wherein the internal address is to be sentback to SYS A, then the program will proceed to a function block 5914 totransmit this SYS B address back to the internal side of SYS A and thento a function block 5916 to store the SYS B address in the SYS Adatabase. However, in the preferred embodiment, the program will flowalong the “N” path to an End block 5924.

Referring now to FIG. 58, there is illustrated a flow chart depictingthe operation of propagating the data from the internal side of SYS Bdown to the internal components thereof, such as the conversion server,the router, etc. The program is initiated at a start block 5802 and thenproceeds to a function block 5804 to create a filter database, i.e., toextract the desired information from the external side that was receivedfrom SYS A and map it to the internal side of SYS B, i.e., create datapackets internal to SYS B. This was described hereinabove with referenceto FIG. 45. The program then flows to a function block 5806 to propagatedownward the information to the destination ones of the account servers,such as the conversion server, the router, etc. When this occurs, thedestination device will return the address at the destination device atwhich the information is stored, this indicated by decision block 5810.When the destination address is received, the program will flow fromdecision block 5810 to a function block 5812 wherein a linkage createdin the database associated with the internal side of the ID server ofSYS B. The program will then flow to an End block 5814. It is noted thatwhen the link addresses are created, this link provides a link betweenthe ID server and SYS B and the destination device and also a linkaddress is provided between the SYS B database at the ID server and theexternal side thereof, such that a change in the external side can bepropagated through to the destination device, since the ID server on theinternal side of SYS B has knowledge of where the information came from,i.e., a link to the external side, and knowledge of where theinformation that was mapped from the external side is stored.

Referring now to FIG. 59, there is illustrated a flow chart depictingthe operation of altering data in SYS A, which is initiated at the block5902 and then proceeds to a function block 5904, wherein a transferoperation effected for a change in the SYS A database. The SYS Adatabase on the internal side thereof has knowledge of the fact thatinformation in this database resides in other locations on a network andremote locations on other networks. When a change is made to thedatabase, these changes are noted and propagated to the external sidesof systems at which the database was downloaded. This is indicated by afunction block 5906. Once a flag or such is set on the external side ofany one of the systems to which data from SYS A was downloaded, theinternal side will recognize this flag as being set, i.e., recognize thechange, and then a determination will be made as to whether thisinformation was actually mapped to the internal side thereof. This isindicated by an operation in a decision block 5908. If the informationis not in the filtered database, i.e., it was never mapped, then theprogram proceeds along the “N” path to an End Block 5910. If the datawas mapped, then the program will flow along the “Y” path to map the newdata over to the internal side of SYS B, i.e., make the change in thedatabase at the ID server, and then “push” this change downward to thedestination devices as indicated by a function block 5912. Once anacknowledgment is received, as indicated by a decision block 5914, theprogram proceeds to the End block 5910.

Conversion Server

Referring now to FIG. 60, there is illustrated a diagrammatic view ofthe Conversion Server operation. The Conversion Server, as describedhereinabove, provides an operation wherein data and/or ID packets aretransferred thereto for general processing in the intermediate or IDpacket domain. However, when data is “pulled” from a host system or“pushed” to the host system, the host system will operate in its nativedatabase structure and language, i.e., there will be a predeterminedformat for that data. When two hosts must transfer data therebetween,some type of adaptor or conversion operation is required. The databasesneed not be totally different systems, but can merely be configureddifferently. For example, there may be an option on one database toselect the format of a vendor code that is comprised of alpha charactersas opposed to numeric characters, or it could be that the vendor isdefined with a different value, albeit in the same format (this due tobeing defined independent of other systems). The vendor would beassigned a universal packet unique to that vendor such that, wheneverinformation was being transferred from one system to the other, it wouldfirst be converted to the ID packet, this information transferred overto the next system and then converted from the ID packet over to thenative format for the destination system.

With further reference to FIG. 60, there are illustrated two hosts, ahost A 6002 and a host B 6004. Host A has associated therewith a nativedatabase 6006 which is formatted and structured in accordance with thestructure of the database. Similarly, the host B has associatedtherewith a native database 6008. Whenever information is transferredbetween the two databases, there must be some type of conversionoperation. Consider the example where data is transferred from host A tohost B. In this configuration, data must be pushed from the database6006 over to the system (or it could be pulled, which will be describedin more detail hereinbelow hereinbelow). A data manager 6010 is providedat host A which is operable to run a program that will fetch data fromthe native database 6006 and transfer it to the system. As describedhereinabove, this data manager 6010 is an Extent that is a program thatruns on or proximate to the host 6002. This Extent, when initiated, willfetch data in blocks and in a predetermined order. There are manyoperations that can be performed on the data in order to efficientlyextract it and transfer it to the system. In addition, as also describedhereinabove, every time data is fetched from the database 6006, therewill be a proprietary address assigned to a proprietary column in thedatabase 6006 in association with a time stamp. Of course, if aproprietary address had already been assigned, it will not be updated.This is for the purpose of keeping track of the data in the database6006 without regard to any restructuring of the data therein. This isnot a host A address.

Once data is pulled from database 6006, it is routed in its nativeformat to a data conversion block 6012. This is the Conversion Server.As described hereinabove, this operation requires first creating atransaction packet and transferring the data in accordance with variouschannel and feed ID packets. This will first, as described hereinabove,be sent to the router for redistribution to the Conversion Server. Forsimplicity, a direct path is illustrated to the conversion operation.

In the conversion operation, the data is converted from the nativeformat for database 6006 into an ID packet. These ID packets, asdescribed hereinabove, were generated at the ID server and populateddown to the Conversion Server. This Conversion Server will convert thedata from the native data to an ID packet and store these in a database,represented by a table 6014. In this table, the data will be structuredsuch that there is a relation between the ID packet, the address in theA database (this will be the address that is stamped into the data bythe data manager 6010) and the information associated with theinformation from the database 6006 in addition to a pointer therefor.This pointer would be such a thing as a vendor ID. Once this has beencreated, the data can then be transferred to a processing block 6016 forprocessing the ID packet domain. This process typically takes place atthe Conversion Server but can be transferred to another ConversionServer through the system or to another processing node. In any event,all processing can be effected with the ID packets in the ID packetdomain. Such things as layering, consolidation and merging can beperformed utilizing the ID packets. Since an ID packet is a definedlength and each ID packet is unique, this facilitates the layeringoperation and also facilitates transfer of information (this dueprimarily to the finite length of a packet rather than the variablelength packet). By substituting the ID packet as the index, then groupsof data can be transferred with a single ID packet, i.e, a vendor ID,the address, etc., associated therewith, thus reducing datatransmission. This advantage will be realized in EDI to a large extent.

Once processed, the processed data in the form of the ID packets aresent to a second data Conversion Server 6018 for conversion from the IDpacket to the native language or structure of the database 6008. This isreflected in a storage table 6020. This is then transferred to thedatabase 6008 by first transferring it in the native language to a datamanger 6022 associated with the host B.

Although this transaction is illustrated as being pushed from host A tohost B, it could be that host B would request information from host Aand, “pull” the data therefrom. Further, there can be a process runningin the process block 6016 that requires more data and can actually pulldata from the respective host A or host B for the processing operation.This is merely a function of the type of Extent that runs on any singlenode in the system, noting that the operation of transferring betweennodes is facilitated with Extents, i.e., the Extents comprise theinput/output of each node.

Referring now to FIG. 61, there is illustrated a flow chart depictingthe operation of the conversion operation, which is initiated at a block6102 and then proceeds to a function block 6104 wherein the data ispushed/pulled and transferred from host A, for example, to theConversion Server. The program then flows to a function block 6106 toconvert the data to an ID packet format and then to a function block6106 to convert the data to the native language of host B. The programthen flows to a function block 6108 to push/pull data between theConversion Server and the host B and then the program flows to an Endblock 6110.

Referring now to FIG. 62, there is illustrated a flow chart depictingthe operation of the data manger, i.e., the Extent running at one of thehosts. This is initiated at a block 6102 and then proceeds to a decisionblock 6204 to determine if this is a push or pull operation. If it is apull operation, the program will flow to a decision block 6206 to awaitan external request for data from another node in the system, at whichtime it will flow along a “Y” path to a function block 6208 to fetchdata and then stamp the address and time if necessary. The program willthen flow to a function block 6210 to create a transaction packet andthen to a function block 6212 in order to transfer this data to arouter, which operation will result in the data being transferred to theConversion Server. The reason for this is that the Extent creates atransaction packet having associated therewith feed and channel IDpackets that define the route to the Conversion Server and eventually tothe destination server, i.e., host B in the example hereinabove. Aftertransferring to the router, the program will flow back to the input offunction block 6204.

If the operation were a push operation, then the program would flow fromdecision block 6204 to a decision block 6214 in order to determine ifthe operation in the push mode has been completed. If not, the programflows to the function block 6208 in order to fetch the data, create thetransaction packet and then transfer the transaction packet to therouter. This will continue until all of the data necessary istransferred, at which time the program will flow along the “Y” path backto the input of decision block 6204 from decision block 6214.

Referring now to FIG. 63, there is illustrated a diagrammatic view forone operation of the Conversion Server, i.e., that utilized for aconsolidation operation. In a consolidation operation, there is providedsome type of mapping function which takes information from two similaror dissimilar databases and consolidates them into a single format. Oneexample of this is a company having a large number of sub-companies,each having a general ledger associated therewith. In this generalledger, there will be associated a plurality of charts of accounts(COA). There may be thousands of account definitions in each Chart ofAccount for each of the sub-companies. The problem is that a centraloffice does not desire to have all of this detail, i.e., they wish toconsolidate a large amount of information into a single account record.For example, it could be that one company would discriminate expensesassociated with delivering documents into such things as First ClassMail, Express Mail, overnight couriers, hand delivery, etc. and keeptrack of each one of these expenses in a separate chart of account. Itmay be that a central system only desires to have a single accountreferred to as “Postage” wherein all of these accounts would be mappedthereto. Therefore, there must be provided some type of mapping functionwhich allows this to occur. In the embodiment of FIG. 63, there isprovided a first company having a COA 6302 wherein there are provided350 separate accounts, and a second company having a COA 6304 with 250accounts defined therein. It is desirable to map these into a single COA6306 with only 150 accounts. Therefore, for each account in the separateCOAs, there must be some type of mapping function. There is provided amapping function 6310 for mapping from COA 6302 into 6306 and a mapping.function 6312 for mapping from the COA 6304 into the COA 6306.Additionally, it may be that this mapping function must work between twodissimilar systems.

With use of the Conversion Server described hereinabove, an ID packet iscreated which defines the final consolidated account in the COA 6306.This ID packet may be, for example, defined as “postage expense.” The IDpacket would have an association in the ID server that would associateit with all of the other accounts associated with its company and in itscompany's native database. Therefore, whenever information for one orall of the accounts associated with the one ID packet were transferredto the associated mapping block, i.e., the Conversion Server, it wouldbe recognized through a matching or searching operation that thisparticular account and the associated records would be associated withthis ID packet and then they would be transferred to the COA 6306 in anID packet format. At the destination, this ID packet would then beconverted into the account associated therewith in its native databaseand then an update performed.

Referring now to FIG. 64, there is illustrated a flow chart depictingthis operation, which is initiated at a start block 6402 and thenproceeds to a function block 6404 to fetch the record or the account inthe above example. This is then forwarded to the Conversion Server, asindicated by a function block 6406 and then proceeds to a decision block6408 to determine if there is an ID packet match. If the ID packetexists, then a simple conversion is performed and the program flows to afunction block 6410 to select the ID packet and then transfer theinformation associated with this ID packet to the destination systemutilizing the ID packet as a pointer, as indicated by a function block6412, the program then flowing to a block 6414 to return the program.However, if the system determined that there were no ID packet match,i.e., that nobody had associated the account with a particular IDpacket, this would result in an error and the program will flow along an“N” path from decision block 6408 to a function block 6416 in order toupdate and define the particular ID packet. Once an ID packet isdefined, it would be defined at the ID server and then propagated downto the Conversion Server. The program would then flow back to the inputof the decision block 6408 to again perform the matching operation, atwhich time it would proceed along the path to the destination.

Referring now to FIG. 65, there is illustrated a flow chart depictingthe operation of the update and definition process, which is initiatedat a block 6502 and then proceeds to a function block 6504. Functionblock 6402 represents a system wherein the user will be prompted to makea selection, this operation typically performed at the ID server. Theuser will typically be provided a large number of accounts from which toselect, these being the accounts at the destination, i.e., the point towhich they are consolidated. The user will make a selection to, forexample, associate a courier service with postage expense. This may beperformed by the user at the sub-company or it may be performed at acentral area. In any event, this ID packet must be generated at the IDserver associated with the system that is transferring data. It couldbe, however, that the ID packet was generated at a central ID server andthen propagated down to the local ID server.

Once the user or system administrator has made a selection, as indicatedby decision block 6506, the program will flow to a function block 6508to update the ID server and the associated packet with this relationalinformation. Once the ID packet has been updated, i.e., the same IDpacket that existed before but with the additional relational linksprovided, the program will flow to a function block 6510 wherein thisupdated ID will be propagated down to the Conversion Server to replacethe previous ID packet. The program will then flow to a return block6512.

Router

Referring now to FIG. 66, there is illustrated a diagrammatic view ofillustrating a router 6602 that is interfaced with a local network 6604.The router 6602, as described hereinabove, is basically the trafficdirector for the entire transaction that occurs in the system. Therouter 6602 has associated therewith a database 6606, wherein the router6602 is operable to store various Extents and data, including somelogging information. The router 6602 is operable to receive a messagefrom any node in the system at any point in the process wherein therouter 6602 is to relay that message or information. The message and itsassociated data will come to the router 6602 with the particular Feed IDand channel information (Channel ID) as described hereinabove. Therouter will receive the information and process it in accordance withthe particular program or transaction associated therewith (thetransaction defined by a unique Transaction ID). This is determined fromthe Channel ID and Feed ID. With the Feed ID as described hereinabove,the router 6602 is aware of the position within the transaction at whichthe transaction is presently disposed. The router 6602, in accordancewith the Extent associated therewith, can then make a decision as to thenext node in the path to which the transaction is to be routed forprocessing and that transaction packet will then be transferred to thenext node in the path, this possibly being a conversion server, adestination or some other node. When the data is received, it is storedlocally or in the archive server somewhere on the network 6604, and thenthe data is transferred as will be described hereinbelow, the reason forthis being to ensure that the transaction is complete. If for somereason, the router 6602 were not to receive an acknowledgment signalfrom the node to which the transaction packet were transferredindicating that the transaction were received and properly processed,the router 6602 could “replay” that portion of the transaction from thearchived image in the archive server or from local archiving. The routeralso keeps track of the amount of time that should pass before anacknowledgment is received from the node to which the transaction packetwas transmitted representing that the information was received. Forexample, if data were transferred to a conversion server for performinga conversion operation thereon and then transmission back to the router,the router would be aware of the amount of time that would be requiredfor the conversion server to achieve such conversion. If a certainamount of time had passed without receiving the transaction packet backfor further routing in accordance with the overall transaction, therouter 6602 would then “poll” the conversion server to determine thestatus of the processing and then possibly replay the previoustransmission or indicate a system failure if that were the case.

Referring now to FIG. 67, there is illustrated a flow diagram forillustrating how a transaction packet is transferred through the systemfrom the host or originating node to a destination node and how the datais stored during this operation. A host 6702 is illustrated having adatabase 6704 associated therewith. In the exemplary transaction, thedata in the database 6704 is extracted and transferred to the router6602 along the network 6604. The router 6602 and its database 6606stores the data in the form that it was retrieved from database 6704. Atthis point, the data basically is relayed, but it might be differentthan the data originally received. This data is referred to as DATA′.This DATA′ is transferred to a conversion server 6706 which is operableto convert the data to a new version as DATA″. However, prior toconverting the data, the data received from the router 6602 at thispoint in the transaction, DATA′, is stored in a database 6708. If, forsome reason, the data did not get transferred back to the router 6602 aswould be the case in this transaction, then the conversion server 6706could reconvert the data and again try to transfer it to the router6602. Once the DATA″ is received at router 6602, a copy of this data isstored in database 6606 and then the data either transferred out ormodified slightly as DATA′″. It is important to note that anytime a copyof data is stored by any of the nodes in the system, other than theoriginal host node, this may typically be stored in the separate archiveserver.

Also, the data stored as DATA′ and DATA″, etc., comprises not only thedata that is received, but the entire message associated therewith inthe form of the transaction packet and the such. This will allow areplay from that exact point in the transaction.

The router 6602 is illustrated as transferring the DATA′″ to a secondconversion server 6710 which also has a database 6712 associatedtherewith, wherein the received DATA′″ will be stored therein. The datais then converted to DATA^(iv) which is then transferred back to therouter 6602, but, wherein the DATA^(iv) will be stored in database 6606.This is the end of the transaction and the next step will be to transferthe data to the destination node 6714. The data will be transferred asDATA^(v), this being the final data. Again, the router 6602 may modifythis data slightly or just relay the data. When the data is transferredto the destination server 6714, it is stored in the destination server6714 database 6716 as the received data and then processed in accordancewith the processes at the destination node 6714. In addition, the router6602 will transfer the final data to an archive server 6718 which has adatabase 6720 associated therewith. In the database 6720, both theoriginal data, DATA, and the final data, DATA^(v) will be storedtherein. As soon as any of the intermediate data is determined to havebeen accurately processed and transferred, the copy thereof will beerased from the link. However, prior to this last transfer, i.e., whenthe router 6602 has been apprised of the fact that the data has beeneffectively transferred to the destination at 6714, a copy of the datain each form along the entire transaction process will be stored in adatabase somewhere, such that it can be retrieved. It may be that allthe data is stored in database 6720 associated with the archive server6718 or stored in the database 6606. In any event, there is provided apointer that allows the router 6602 access to the data at any point inthe transaction and provides the ability to have a logging capability.As described hereinabove, each step of the transaction process isrecorded such that a failure, if it occurs, will be determined by thevalue of the Feed ID, it being remembered that the Feed ID isincremented for each step in the transaction, and the state of the datathereat. Therefore, by examining all the data in the transactionprocess, as the data is processed through each step of the transaction,the position in the transaction that the failure occurred can bedetermined. However, once the transaction is complete, it is notnecessary to maintain the intermediate copies of the data in the variousprocess forms along the transaction path.

Referring now to FIG. 68, there is illustrated a flow chart depictingthe operation of initiating a process. The process is initiated at ablock 6802 and then proceeds to a block 6804 wherein transaction IDS areassigned to a particular transaction, this being the “Run ID.” Theprogram then proceeds to the function block 6806 wherein the data isparsed. As described hereinabove, data is typically parsed into blocksinto data to divide the data up for processing purposes. Otherwise, oncea transaction is initiated, the entire system must be dedicated toprocessing the all data associated with that transaction. By parsing thedata into blocks, the transaction can be divided up into smaller, moremanageable transactions. The program then proceeds to function block6808 to assign block IDS to each block, it being remembered that eachblock will be associated with the particular Run ID of the transaction.The program then flows to a function block 6810 to assign Feed IDS andChannel IDS to each block and to function block 6812 to associate thefirst block to the value of “1.” The program then flows to a functionblock 6814 to fetch that particular block and then to a function block6816 to process the fetched block of data in accordance with theparticular Extent that is being operated. The program then flows to adecision block 6818 to determine if more blocks are required, i.e., havethe maximum number of blocks been retrieved? If not, the program willflow through the function block 6820 to increment the block value andthen to the input of function block 6814. When all blocks have beenfetched and processed, the program will flow to an End block 6822.

In the flow chart of FIG. 68, when the Feed IDS are assigned to eachblock, the Extent associated therewith can determine that differentrouters can be used for different blocks, i.e., the actual transactioncan be divided up into different paths with different Channel IDS in thenetwork. This, of course, assumes that there are multiple routersavailable and the Extent will have a router list defining the availablerouters. Any of the routers can be utilized depending upon theiravailability and the underlying program associated with the Extent.There may even be a priority associated with routers in the routertable. This in effect allows the channel IDS to be conditional andflexible. This will in effect allow a particular Extent to have accessto multiple channel IDs, the primary connector being a common RUN ID.When a node such as a router receives the message, it can determine fromthe channel ID where the next node in the path is.

Referring now to FIG. 69, there is illustrated a diagrammatic view ofthe multiple processing paths through the network. The host 6702 isoperable to extract the various blocks from the database 6704 and thenprocess them through multiple routers. There is provided, in oneembodiment, a master router 6902 that monitors the operation of aplurality of other routers 6904 on the system that are available to thehost 6702 and its associated Extent. The host 6702 could divide theblocks equally among all of the routers. When each of the routersreceives information, it will apprise the master router 6902 of theprocess that is being run thereon and, when the individual router 6904or the master router 6902 transfers the data finally to the destinationof 6714, then each of the routers will apprise the master router 6902 ofthe completion of the task. The master router 6902 may, in oneembodiment, keep track of copies of the data transferred thereto. Thisdata is either stored on the local databases of each of the routers 6904or the router 6902, or on the archive server 6718. In any event, thereis provided a single traffic manager for the transaction in thisembodiment.

Referring now to FIG. 70, there is illustrated a flow chart depictingthe operation of the destination node 6714 receiving the data, which isinitiated in block 7002 and then proceeds to a decision block 7004 todetermine if a transaction message has been received. If so, the programwill flow along a “Y” path 7006 to read the transaction ID on thetransaction and then to a function block 7008 to read the program IDwhich is also associated with each transaction that it is transmitting.The reason for this is to ensure that each block that is received fromwhatever router 6904 is associated with the particular transaction. Theblock ID is then read as indicated by function block 7010 and then thisblock of data is stored as indicated by function block 7012. When allblocks have been received as indicated by decision block 7014, then theycan be assembled, it being noted that they could actually be receivedout of sequence. However, with the block IDS, they can be sequenced bythe destination 6714 and the Extent running thereon. Once all blockshave been received, the program flows to a function block. 7016 to sendan acknowledgment back to the master router 6902. Alternatively, eachrouter could apprise the master router 6902 of the completed transfer.The program then flows to an End block 7018.

Referring now to FIG. 71, there is illustrated a flow chart depictingthe operation of the router. The program is initiated at a block 7102and then proceeds to a decision block 7104 to determine if a message hasbeen received, wherein the program will flow along a “Y” path to afunction block 7106 to process the message and then to a function block7108 to increment the Feed ID and then to a function block 7110 to sendthe message and records to the archive server or store locally. This isa copy of the message that was received and the data associatedtherewith. This is for the purpose of logging the data at this point inthe transaction, as described hereinabove. A process pointer is thencreated which is logged into a node log, that node log associated withthat particular router, this indicated by function block 7112. Thisinformation could also be logged into a master log on the master router6902. The program then flows to a decision block 7114 to determine ifthe process is complete. If not, the program will flow to a decisionblock 7116 along the “N” path to determine if a “time out” condition hasoccurred. If there has not been a sufficient amount of time that haspassed since the information was transmitted to another node forprocessing, the program will flow along the “N” path back to the inputof decision block 7104. Decision block 7104 will, if no message has beenreceived, proceed along the “N” path back to the input of the time outblock 7116. This will continue in this loop until a time out situationhas occurred or another message has been received and processed. If thetime out condition for a particular process has occurred, the programwill then flow along a “Y” path to poll the particular process in theother node as indicated by function block 7118 and then proceed back tothe input of decision block 7104.

Once the process has been complete, the program will flow from thedecision block 7114 to the function block 7116. This completion of theprocess means that all steps in the process have been complete, i.e.,the entire transaction has been complete and information has beentransferred to the destination node. Once this occurs, the individualrecords for each step in the transaction can be erased from the archiveserver (on the local node) indicated by the function block 7120 and thenthe program flows to a function block 7122 wherein the start and the endrecords will be stored as described hereinabove, and then the programflows to an End block 7124. The start records provide a means for theentire transaction to be restarted.

Referring now to FIG. 72, there is illustrated a flow chart depictingthe polling process which is initiated at a block 7202 and then proceedsto a function block 7204 wherein the particular node that is currentlyprocessing the transaction will be polled. This is an operation whereinthe router will send a request to the particular node to determine thestatus of the transaction. The program will flow to a decision block7206 to determine if the node that is polled is currently processingdata. If not, the program will flow along a “N” path to first determineif the maximum number of replays has occurred at a decision block 7208and, if not, the program will flow to a function block 7210 along the“N” path to replay the image of the data at the previous point in thetransaction. The program will then flow to a function block 7212 whereinthe replay counter will be incremented and then flow to a Return block7214. If, however, the decision block 7206 had determined that theprocessing had stalled or that it was not processing at all, then theprogram would flow along a “Y” path to a function block 7216 to send analert and then to a block 7218 to abort the operation.

Load Monitor

Referring now to FIG. 73, there is illustrated a diagrammatic view oflocal network 7302 wherein a plurality of routers 7304 are provided anda plurality of conversion servers 7306 are provided. There is provided amonitor block 7308 that is operable to monitor the load on each of thenodes that can be accessed for any given transaction over the network7302 which is typically originated at the host 7310. The load monitor7308 is a load monitor. It determines the transaction load on each ofthe nodes and then “pushes” this information to the host to apprize thehost of which nodes, such as routers, are available for transactions.This is'such that, although they may not actually be totally loaded downat the present moment but, due to the fact that the router has knowledgeof the amount of data that is coming to it from another node in aparticular transaction, the router can determine that its future loadwill be too great to handle other transactions. The load monitor 7308will be apprized of the load for each of the subject nodes that reportload, such as the routers, and then the load monitor will inform thetransaction originating node, such as the host 7310, that any particularnode in the path is not available for a particular transaction.

Referring now to FIG. 74, there is illustrated a flow chart depictingthe determination of the transaction load on a particular node, such asthe router, which is initiated at a block 7402 and then proceeds to adecision block 7404 to determine if the message has been received. Ifso, the program will flow to a function block 7406 to determine thetransaction that is being run. Typically, a particular router or nodewill have run the particular transaction in a prior operation and itwill have knowledge of the amount of CPU time that is required to bededicated to a particular transaction, memory, disk space, communicationload or any other resources necessary to efficiently complete thetransaction. For example, if a number of blocks of data were to betransferred to any particular transaction, the particular router, forexample, would have knowledge of how much CPU time will be required inthe immediate future. This will determine how many other transactions itcan actually service. It is noted that the actual message that itreceives initially will not necessarily require a lot of CPU time tohandle this transaction. However, it could be that a router couldreceive multiple messages from different nodes or from the same nodeindicating multiple transactions that are to be routed through therouter along different channel IDs and for different RUN IDS. It couldalso be that the router is awaiting large amounts of data to betransmitted thereto from a conversion server in a particular transactionand, therefore, the router may want to reserve its processing time tohandle this particular transaction. This is facilitated by examiningstatistics for a particular transaction that are stored in associationwith the local CPU of that particular node as indicated by functionblock 7408. These are examined in response to receiving a message in theform of the transaction packet that provides all information to therouter as to the type of transaction that is associated with thattransaction. Note that the originating node does not request of therouter if it can handle the load or even provide specific information asto the transaction being handled. It is the transaction type and thelocally running Extent that identifies the transaction to the router.

Once received, a determination is made as to the immediate future loadneeds for that particular router or node as indicated by function block7410. Once the load is determined, i.e., in the percent of future CPUtime or resources that are required for a particular transaction, thisload information is pushed to the load monitor 7308 as indicated by afunction block 7412. The program then proceeds to a decision block 7416to determine if the transaction is complete, i.e., all of the necessarytransactions have been processed from the various conversion servers,etc., along the transaction path. Once this is complete, the statisticswill be updated, as indicated by a function block 7412, to take theaverage of the statistics for the given transaction over multipletransactions. When the transaction is initially set up in the system,there will be some average time attributed to that transaction as aninitialization of the system. This will then be updated for a particularnode, since there could be faster CPU's or slower CPU's involved invarious nodes. Once the statistics have been updated locally, then theload monitor 7308 is apprized of the fact that the transaction iscomplete and the load has actually decreased on the particular node, asindicated by function block 7414. The program then proceeds to an Endblock 7416.

Referring now to FIG. 75, there is illustrated a flow chart depictingthe operation of the load monitor 7308. This is initiated at a block7502 and then proceeds to a decision block 7504 to determine if anupdate has been received thereby, this being a “push” operation. Once anupdate is received, the program proceeds from the decision block 7504along a “Y” path to a decision block 7506 to determine if the receivedload on the node has exceeded the threshold for that node. If not, theprogram will flow back to the input of the decision block 7504 along the“N” path. Whenever it does exceed the threshold, this indicates thatthis particular node should be taken offline as to other nodes in thesystem that wish to use this particular node along the channel ID path.It should be understood that this threshold can be “transaction based.”That is, in certain transactions a large amount of CPU time is requiredfor the router or the conversion server or other features on a givennode. Some transactions, however, may use very little of the CPU time.Therefore, a node may inform the load monitor that its CPU time for agiven transaction will be considerably tied up but that it can allocatea certain amount of its CPU time to short processes, and therefore, itwill still service these other short processes. Therefore, whenever theload update is received, this load update can indicate the particulartransaction that it is handling and that load with respect to thattransaction is very high and the load monitor 7308 can then determine ifthis particular load for that transaction exceeds the thresholds forthat transaction.

Once it has been determined that the threshold has been exceeded, theprogram will flow along the “Y” path from decision block 7506 to afunction block 7508 to “push” this load information to the router listin the nodes, such as that of the host 7310. These router lists arecontained within the Extent that is utilized for a particulartransaction. The load monitor 7308 is aware of the locations of each ofthese Extents that require updating on the router list. This pushoperation indicates to these particular nodes that the router is notpart of the active list anymore. It may even be that a main router listis maintained at a central location and the Extents are operable tocheck these router lists. The program then proceeds to a decision block7510 to insert a predetermined amount of delay in the decision makingprocess and then to a decision block 7512 to determine if informationhas been received back from the router as to a “release” of the routerstatus for the transaction. The load monitor 7502 has knowledge of howlong a particular router should be occupied by a given transaction. Ifthe delay is exceeded, i.e., the router has not come back online, thismight indicate a stalled router. If information has not been receivedwithin a certain amount of time, as indicated by the delay block 7510,then an alert will be sent, as indicated by a function block 7514. Also,the load monitor may have the capability to actually poll the router todetermine if it is still functional. This is a situation wherein aservice technician will be apprised of a potential fault in the system.However, if the router does come back online within the appropriateamount of time, then the decision block 7512 will flow along the “Y”path thereof to a function block 7516 wherein the router list will thereagain be updated by pushing information out to the nodes. The programwill then flow to an End block 7518.

It should be noted that this load monitor operation is one thatdetermines loading of the system and availability of resources basedupon the future load that will be placed upon a particular node, whichdecision is made by the node itself and, in effect allows the load tothe system to be balanced over the system as a whole. The reason thatthis can occur is that each of the nodes has knowledge of thetransaction that is going to be performed, i.e., it knows how much datawill be transferred thereto, how much time will be involved andsubsequent transactions such as receiving information back from aconversion server, etc. It may be that, at the time the particulartransaction is initiated, that the actual CPU time involved in theinitial handling of the message is very small. It is the knowledge ofthe transaction that is going to be processed that allows a particularCPU to indicate a heavy future load due to expected data and transactioninformation or traffic that will occur. This is only possible since thetransaction being performed is known at a particular node.

Referring now to FIG. 76, there is illustrated a diagrammatic view of atransaction that occurs between two companies, a company 7602 referredto as company “A” and a company 7604 referred to as company “B”. CompanyA has a local network 7606, a router 7608, an archive server 7610, ahost node 7612 and a conversion server 7614. Similarly, Company B has alocal network 7620, a router 7622, a host node 7624 and a conversionserver 7626, all these by way of example, it being understood that manyother nodes as described hereinabove could be implemented, for example,an archive server at Company B.

When a transaction occurs wherein host 7612 at Company A desires totransfer to host 7624 at Company B as a destination certain information,all of the necessary conversions in the company will be carried out in agiven transaction, which transaction results in information beingtransferred from router 7608 at Company A along a gateway at 7630 to therouter 7622 for Company B. Router 7608 is the traffic manager forCompany A, whereas router 7622 is the traffic manager for information atCompany B. Therefore, router 7608 will store all transactionalinformation regarding each step of the transaction, copy the data, etc.,in the archive server 7610. However, if there is a problem with thegateway 7630 or with the operation of the router 7622, the router 7608will carry out the transaction all the way up to the completion thereofwhich is ready for transfer to the router 7622. If the transfer of thatinformation fails, the router 7608 views this as a completed transactionfrom the standpoint of processing, and will store the beginning and endinformation on the archive server 7610 and then provide an alert toCompany B. When the router at Company B comes back online and it is onlynecessary for the router 7622 then to “pull” the information from thearchive server 7610. The router 7622 has knowledge that a transactionwas initiated, but never completed and, as such, it really needs to goback to the last point in the transaction at Company A to pull theinformation therefrom.

Referring now to FIG. 77, there is illustrated a flow chart depictingthe operation of pulling information from one company to another overthe gateway. This is initiated at a block 7702 and then proceeds to afunction block 7704 wherein a restart operation occurs, wherein thefailed component at Company B comes back online, or is available forprocessing. It may be that the router 7622 was just busy with anothertransaction and caused the router 7608 to terminate the transfer untilrequested by router 7622. When the restart operation is complete, theprogram will flow to a decision block 7706 to determine if the processwas complete at Company A. If so, the program will flow along the “Y”path to function block 7708 to pull the transaction from the archiveserver 7610 at Company A and then to a block 7710 to continue. If theprocess were not complete, then the program would have flown aroundblock 7708 to the block 7710 to await completion of the transaction atCompany A and subsequent transfer thereof to Company B.

Referring now to FIG. 78, there is illustrated a flow chart depictingthe operation at a conversion server wherein a conversion server fails,initiated out of block 7802. The program then flows to decision block7804 to await the receipt of a message and then to function block 7806to process the data in accordance with the Extent and the functionalityof the conversion server for that particular transaction. The programthen proceeds to a decision block 7810 to determine if the operation atthe conversion server has been completed. If so, the program will flowalong the “Y” path to a function block 7812 to transfer the completedand converted information to the router and then the Feed ID will beincremented in the transaction path as described hereinabove. Theprogram will then flow to an End block 7814.

However, if the operation is not complete, then the operation will flowfrom the decision block 7810 along the “N” path to a function block 7816to move the unprocessed data to the archive server. This is the datathat was originally received by the conversion server, i.e., this is animage of the data at that point in the transaction. Once this is movedto the archive server then an alert is sent to a technician, asindicated by a function block 7818 or this alert can be sent back to therouter. It could be that the router can make a decision to forward thisto another conversion server as a conditional branch, i.e., substituteanother conversion server in the channel ID for that particulartransaction.

In operation of the conversion server or of any processing node in thesystem, there are provisions for the processing node to stop processing.The termination of processing could be the result of a failure at thenode in the processing operation thereof, and instruction from a routeror some type of master process director to pause the processingoperation or an approval step. Each of these will be describedhereinbelow.

If, during the processing, there is a failure in the processing, thiscould result in the processing node being at a condition wherein theprocessing capability, i.e., the resources, of the node are occupied bythis terminated process. In this event, all of the informationassociated with that process, including the data, the state thereof andany log information associated with the process will be transferred toan external archive server. This will clear up the memory and storageresources on the processing node and also clear up the processingcapability thereof to allow this processing node to be utilized forother processing. Thereafter, an alert will be sent out to a technicianor the such that the processing has failed and that a pointer will beprovided indicating to the technician or such where the data is stored,such that a technician can then examine this data and continue theprocessing if necessary with the same node or with another node. Therecould even be an instruction provided to the router to replay thetransmission to the conversion server or instruct the conversion serverto replay the process from the starting point again after somemodification was made to the Extent (if necessary) that runs theprocessing program.

In a pause condition, an external command can be generated and forwardedto the processing node such as the conversion server to pause theoperation thereof. This may be facilitated for the purpose of passingthrough another process that has a higher priority or making somedecision as to termination of the process. This is similar to thatassociated with the print manager on a computer where any number ofprint jobs have been queued. It is possible to actually, in the middleof printing, to pause a print job. This takes the print job out of thequeue and allows other print jobs to process in the queue.Alternatively, the entire printer operation can be paused also. In thepause feature in the present disclosure with respect to the processingnode, once it is paused, then the information and data associatedtherewith is moved from the processing node to a remote device untilsome action is taken, such as restarting the process.

In the approval method, a process is run on the processing node thatrequires an approval prior to allowing the process to continue. It maybe that certain transactions have been generated and completed at theprocessing node such as the conversion server that are ready to betransferred to another node to continue the processing thereof. Once theprocessing is complete at that node, a request for approval is sent outto a technician or the such. If the technician then will take whateveraction is necessary and send the appropriate approval, upon receivingthe approval, the processing will continue. However, if the approval isnot received in a certain amount of time, then the information at thatprocessing state is transferred to an external node such as the archiveserver until the request for approval is received. Once the request forapproval is received, then that processing node can access theinformation back and continue processing at the node from the last pointin the processing operation. The reason for this is to clear up theresources on that processing node. Alternatively, it could be that, assoon as the processing is complete, the information is transferred tothe archive server and the request for approval sent out.

Monitoring/Logging

Referring now to FIG. 79, there is illustrated a diagrammatic view ofthe logging and monitoring operation. There is illustrated in FIG. 79 aplurality of “boxes” that are connected to a network mesh 7902. Theboxes that are illustrated are a router 7904 and an archive server 7906,in addition to a log server 7908. A global monitor server 7910 is alsoprovided. The router 7904 has associated therewith a router monitoringblock 7912 and the archive server 7906 has associated therewith anarchive monitoring block 7914. The log server 7908 has providedtherewith an association with a local database 7916 and an externaldatabase 7918, the operation of which will be described hereinbelow. Themonitoring is illustrated as being distributed among the differentboxes. However, monitoring can be facilitated at any one box or serverand have access to other servers. The illustration in FIG. 79 isintended to illustrate that the monitoring functionality is separate,although some of the monitoring functionality can be combined indifferent boxes.

In addition to providing the log server 7908 as a separate log server,each of the boxes will have associated therewith a local loggingfunction. This is illustrated at the router 7904, which has a local logfunction 7922 associated therewith. Therefore, the router 7904, incarrying out the processes associated therewith, can also log theprogress of the process thereon. Additionally, certain informationassociated with running of the process on the router can be forwardedover to the log server 7908.

In operation of the router, as described hereinabove, there are certainmonitoring functions that are directed toward resources that areavailable to other systems in the distributed processing system, such asthe host. When a channel is defined, a router will be associated withthat channel. The router monitoring block 7912 will facilitate differentrouters to be utilized for a single transaction or multiple routers tobe utilized for a given transaction. The router monitoring 7912 canmonitor multiple routers or it can merely monitor the router 7904 in alocal monitoring manner to acquire information as of the resourcesassociated therewith. The archive monitoring block 7914 monitorsinterface of the archive server 7906 with external and internal datastorage locations, as will be described hereinbelow. The globalmonitoring block 7910 monitors the overall transaction flow throughoutthe whole system to ensure that a transaction has been completed and, ifnot, it can then notify the appropriate resource that the transactionhas not been completed and log this information in the log server 7904.

Referring now to FIG. 80, there is illustrated a block diagram of thearchive server 7906. In general, the archive server is comprised of acentral control server 8002, which can interface with a plurality ofarchive storage devices 8004, of which three are illustrated. Thecontrol server 8002 is operable to make a determination as to whereinformation is to be stored, i.e., to which of the archive storagedevices 8004 the information is to be directed to. Initially, one of thestorage devices 8004 will be a local storage device. However, the otherarchive storage devices could be tape storage devices, offsite storagedevices and any type of storage device. The control server 8002 merelyrequires knowledge of where the information is stored, such that it canbe retrieved at a later time. Therefore, the control server 8002 willcreate a pointer that will define the address in the archive space atwhich the information is stored. This pointer is stored in a pointerdatabase 8004. Therefore, whenever information is received to be storedor archived, a pointer is created, stored in the pointer database 8004and then the archived information routed to the appropriate archivelocation.

Referring now to FIG. 81, there is illustrated a flow chart depictingthe operation of local logging, which is initiated at a block 8102 andthen proceeds along two paths. The first is to a function block 8104 tomonitor the local resources. At each “box” in the system, such as therouter, the conversion server, etc., where processes are run in anyaspect of the transaction, the local resources dedicated to running thisprocess will be monitored. These are such things as the amount of memoryavailable or utilized, the amount of CPU time being utilized as afunction of the available CPU time, the hard disk storage space, etc.The use of these resources is determined in accordance with knowntechniques and then these resources are stored locally, as indicated byfunction block 8106. These resources, or a portion thereof, can befiltered in accordance with some type of filter, and are thentransferred to the global monitoring block 7910, as indicated by afunction block 8108. The program then proceeds the input of functionblock 8104 to continue the monitoring process. Along the second path,the program flows from the block 8102 to a decision block 8110 todetermine if there is any new transaction activity that has occurred onthe particular (local) box. If not, the program will flow back along an“N” path to the input of function block 8104. When transaction activityhas occurred, the program will flow along the “Y” path to a functionblock 8112 to log this transaction information locally and then to afunction block 8114 to log a transaction activity globally in the globalmonitor block 7910. The program then proceeds to a function block 8116to determine if a process is currently running. If not, the program willflow an “N” path back to the input of decision block 8110. If theprocess is running and executing instructions, the program will flowalong a “Y” path from decision block 8116 to function block 8118 to logthe Program ID, the Feed ID, the Channel ID, the Program ID, the Run ID,the Step ID and the Process ID into the local log and then proceed backto the input of function block 8104. In addition to the other items thatare noted herein that are logged, the Row ID and the Time Stamp are alsostored, this being a generic marker that was provided by the host andwhich defines uniquely the location of this information at the host.

If it were determined when the process were running that there were oneor more errors, then the program would flow from decision block 8116along a “Fault” path to a function block 8120 to log this as an errorand then back to the input of decision block 8116.

The local logging operation basically monitors both the local resourcesand also the process that is running thereon. Each time instructions arecarried out in the local box, this information can be logged, such thatknowledge is available as to wherein the sequence of steps associatedwith the process that the process is currently operating. This isimportant even with respect to errors, such that knowledge is nowavailable as to wherein the process the error occurred.

Referring now to FIG. 82, there is illustrated a flow chart depictingthe global monitoring operation, which is facilitated at the globalmonitor server 7910. However, as also noted hereinabove, the globalmonitoring function could be carried out at any one of the boxes, aslong as there is access to information being transferred to and receivedfrom other nodes on the system.

The global monitoring operation is initiated at a block 8202 and thenproceeds to a function block 8204 to monitor resources on the system,i.e., at each of the various nodes in the system. The program thenproceeds to a function block 8206 to update statistics regarding theseresources. As described hereinabove, the statistics are maintained tohave knowledge of what resources are available and what transactions arebeing carried out on the distributed processing system overall. Theprogram then proceeds to a decision block 8208 to determine if an alerthas been received indicating that there is operation that is required tobe updated as to a new transaction being initiated or some problem withthe transaction. Until this occurs, the system will receive resourceinformation from the remaining nodes. However, once an alert has beenreceived, the program will flow along the “Y” path to a function block8210 to globally log the transaction that is being initiated at one ofthe nodes. This will log the start time of the transaction and allinformation for that transaction, which consists of a plurality of Ids,such as that described hereinabove with respect to information regardingthe Program ID, the Feed ID, the Channel ID, the Program ID, the Run ID,the Step ID, etc. The program then flows to a function block 8212 inorder to start a timer for both the transaction and for the currentprocess step. Each of the transactions will have associated therewith apredetermined amount of time for execution from start to finish (with astatistical variation allowed) and for each process at a given node.Some nodes may run slower than other nodes and, therefore, these nodeswill have different times even for the same transaction. The programthen flows to a function block 8214 to update the resource database,since knowledge of the transaction will indicate to the system whatother resources are going to be required. It is noted that the localsystem merely monitors the actual resources that are being occupiedwhereas the global monitoring system predicts the amount of resourcesthat will be required for a given transaction. This is based on variousinformation about the transaction that the system knows will occur inthe future, such as the number of blocks that are going to be received,etc.

Once the resource database has been updated, the program flows to adecision block 8216 to determine if the process that is being run at aparticular node is complete. It is noted that a transaction, wheninitiated, will involve many different nodes. Each node will inform theglobal monitor of the initiation of the process thereon and whether thatprocess step is complete. It is noted that the router is actually thetraffic director for each transaction that occurs and it monitors aparticular process that has been transferred therefrom to another node.The router will actually keep track of the process and perform theinquires. However, the global monitoring function can be concentrated ina single node or distributed over many nodes with reporting functions toa central node to monitor the flow of the overall transaction Once aprocess step at a given node is complete, as defined by the localsystem, such as a conversion server, the program will flow along a “Y”path to a function block 8218 in order to log this information as beingcomplete and then the program will flow to a decision block 8220 todetermine if the transaction is complete, i.e., if the last process stepcompleted was the last step in the transaction. If not, the program willflow along the “N” path to a function block 8222 in order to proceed tothe next step in the process and then back to input of the functionblock 8212 in order to start a timer for the next step in thetransaction bracket the start timer keeps track of both the time for theentire transaction and also for each step. Once the timer has beenstarted for the next step, the program will determine if the processstep is complete at decision block 8216, log the completion thereof atfunction block 8218 and then flow to decision block 8220 until thetransaction has been completed. This loop will continue through block8222 until completed. Once completed, the program will flow along the“Y” path from decision block 8220 to a function block 8224 to clean upthe log, i.e., to remove intermediate log entries that are notnecessary, since the transaction has been completed. The program willthen flow to a function block 8226 in order to inform the archive serverof the fact that the transaction has been complete, such that thearchive server can then remove intermediate archived informationtherefrom. The program then flows to a return block 8246.

When the program proceeds to the function block 8216, until the processstep is complete, the program will flow along the “N” path to a Time Outdecision block 8228 to determine if the time information set in theblock 8212 for the process is exceeded. If not, the program willcontinue to flow back to the input of decision block 8216. However, ifthe time has been exceeded, i.e., it has been determined that too muchtime has passed for the process to have been performed on the particularnode, the program will flow along a “Y” path to a function block 8230 toinitiate a notification process. This is a process wherein apredetermined individual or process will be notified of the fact thatthe process has not completed in the allotted time. The program willthen proceed to a decision block 8232 to determine if a process restartoperation is to be performed. In some situations, it may be thatprovision is made to restart the process at the node. As describedhereinabove, the archive server maintains a full record of allinformation necessary to restart the process at that node. It is notnecessary to start at the beginning of the transaction but, rather, atthe point in the transaction that the process was started at thatparticular node. If the process restart operation is available and isdesignated, then it will flow along the “Y” path back to the input ofthe decision block 8216 and the timer reset. However, if a predeterminednumber of restart operations has resulted in no success or if theprocess restart option is not available for that node, then the programwill flow along a “N” path to a function block 8234 to log this error inthe log server 7908 and then to a function block 8236 to terminate theprocess. The process is terminated at the node in order to free up theresources of that node. However, when this occurs, all this informationis transferred to the archive server 7906, such that, if necessary, theprocess can again be started at that node. It should be understood thatwhen the process terminates at this point, the transaction is alsoterminated. After the termination of the process, it will proceed to aReturn block 8238.

In addition to logging all the information internally with the logserver 7908, the global monitoring operation will also provide externallog information. For example, when the initiation of a transaction islogged globally, all the transaction information associated with thattransaction will be logged internally. Additionally, as indicated by afunction block 8240, this information is transferred to the externaldatabase 7918 to provide an external log. This external log is a logthat is viewable by a third party. For example, if there were an CompanyA that was in a business relationship with a Company B, Company B mightwant to view transactions that are being carried out for Company B atCompany A. In this event, Company A may want to provide certain filteredinformation to Company B as to a transaction that is operating on thesystem. Any time that a log operation is effected in the globalmonitoring operation, this log will be transferred in some filtered form(or in a complete form) to the external log. Therefore, when the logoperation in function block 8218 is performed, it is also loggedexternally, as indicated by a function block 8242 as well as a functionblock 8244 indicating an external log in the clean up operation infunction block 8224.

Referring now to FIG. 83, there is illustrated a flow chart depictingthe notification process, which is initiated at a block 8302 and thenproceeds to a decision block 8304 to determine if the restart counterhas exceed the maximum value. If it has not, the program will flow alonga “N” path to a function block 8306 to notify the process or individualof the fact that a restart operation has been performed and then arestart signal will be sent to the node, as indicated by a functionblock 8308. This notification of the restart will typically befacilitated through the router that is in the channel associated withthe node operating the process, that node being, for example, aconversion server. The program will, after sending the restart signal,flow to a return block 8310.

If the restart counter has exceeded the maximum number or is equal tothe maximum number, the program will flow along the “Y” path fromdecision block 8304 to a function block 8312 in order to notify theappropriate process or individual, etc. of the failure of the process,i.e., that the process has failed on a particular node and that someintervention needs to be taken. It is noted that the notification can besent to any device or node. At this point in time, the process isessentially terminated and so is the transaction. The program will thenflow to a function block 8314 wherein all of the information regardingthe process, it's failure, and the node on which it failed will betransferred to the archive from the node. This is a command that is sentby the global monitoring operation. The purpose of this is to terminatethe process at the node wherein the failure occurred such that theresources of that node can be released to the overall distributedprocessing system. The point at which the failure occurred will also bestored on the archive server, such that some intervening process oraction by an individual can possibly correct the process, redirect it toanother node to complete the process or some other action. However, itis noted that the transaction need only be started up at this processstep and not at the beginning of the transaction in order to completethe transaction. For example, it could be that a process node hasfailed. The restart operation, of course, will fail and then informationregarding this transaction will be sent to the archive server. As notedhereinabove, the archive server already has information regarding whatwas actually transferred to the failed node, even if the failed nodecannot send that information to the archive server. Therefore, a newnode can be disposed in place of the failed node, or the informationrouted to another node, and the transaction restarted at that point andin the overall transaction.

Referring now to FIG. 84, there is illustrated a flow chart depictingthe restart operation, which is initiated at a block 8402 and thenproceeds to a decision block 8406 to determine if the node has failed.If not, the program will flow to a return block 8106 and, if so, theprogram will flow along a “Y” path to a function block 8408 to basicallychange such things as the Feed ID and the Channel ID parameters to a newDevice ID. This new Device ID is required to allow the process tocontinue on a different node. If not, the program is merely restarted atthe return block 8406.

Referring now to FIG. 85, there is illustrated a flow chart depictingthe archive operation. This is initiated at a block 8502 and thenproceeds to a decision block 8504 to determine if data has beenreceived, i.e., information has been transmitted to the archive server7906 for storage thereat. When data has been received, the program willflow along the “Y” path to a decision block 8506 to determine if memoryis available locally. If so, the program will flow along the “Y” path toa function block 8508 to store the information locally. If not, theprogram will flow to a function block 8510 to store the informationremotely. After storage, the program will flow to a function block 8512in order to store both the pointer to the data at the location of thedata in the pointer database, as represented by function block 8514. Thepointer basically constitutes the Transaction ID, the Run ID and theBlock ID, if all these are present. After creating and storing thepointer in the pointer database, the program flows to an End block 8516.

Referring now to FIG. 86, there is illustrated a flow chart depicting aread operation from the archive server 7906, which is initiated at ablock 8602 and then proceeds to a decision block 8604 to determine if aRead request has been received. If so, the program will flow along a “Y”path to a decision block 8606 to determine the storage location from thepointer by reading the pointer, as indicated by function block 8608. Theread pointer essentially defines the address at the storage location.The program then flows to function block 8610 to retrieve theinformation and then to a return block 8612.

Although the preferred embodiment has been described in detail, itshould be understood that various changes, substitutions and alterationscan be made therein without departing from the spirit and scope of theinvention as defined by the appended claims.

1: A method for monitoring the operation of a distributed transactionsystem that is operable to process one or more transactions, each ofwhich is comprised of a plurality of discrete processes each operatingindependent of each other and operating independent of the entiretransaction, and which transaction as a whole is operable to perform atransaction on data when transferring data from a first location on anetwork to a second location on the network and the transactioncomprised of operating on the data at intermediate nodes in the systemwith one or more of the plurality of discrete processes during thetransaction wherein each of the discrete processes requires informationand data from another previously executed one of the discrete processesprior to transferring data therefrom, comprising the steps of:determining when a transaction has been initiated from the firstlocation and has been transferred to the one of the intermediate nodesin the network; logging the initiation of the transaction at a centrallocation on the network; determining when the initiated transaction hasbeen completed by transfer of the processed data to the second locationon the network from the last of the intermediate nodes in the networkthat has operated on the data; monitoring the length of time that theinitiated one of the plurality of processes requires for completion at agiven one of the intermediate nodes; and logging the completion of thetransaction at the central location on the network in addition to thetime information determined in the step of monitoring. 2: The method ofclaim 1, and further comprising the steps of: determining when one ofthe plurality of processes associated with the initiated transaction hasbeen initiated on the given one of the intermediate nodes associatedwith the initiated transaction; logging the initiation of the one of theplurality of processes that has been initiated at a local location onthe network; determining when the initiated one of the plurality ofprocesses has been completed on the given intermediate node; and loggingthe completion of the initiated one of the plurality of processes at thelocal location on the network. 3: The method of claim 3, wherein thestep of monitoring the length of time that the initiated one of theplurality of processes requires for completion at the given one of theintermediate nodes comprises the steps of: initiating a process timerwhen the initiated one of the plurality of processes has been initiated;comparing the value of the timer with a predetermined process completiontime for the initiated one of the plurality of processes to becompleted; if not completed, logging an error message to the centrallocation that the initiated one of the plurality of processes has notbeen completed within the predetermined process completion time. 4: Themethod of claim 4, wherein the step of logging the error message furtherincludes sending a notification to a predetermined location that theinitiated one of the processes has not been completed during thepredetermined process completion time. 5: The method of claim 4, andfurther comprising the step of determining if the initiated one of theplurality of processes is still running on the given one of theintermediate nodes after a determination of not complete and, if so,then resetting the process timer back by a predetermined amount of timeprior to the step of logging the error message to the central location.6: The method of claim 4, and further comprising the step of monitoringthe process through each step of the process and logging predeterminedinformation regarding each step of the initiated one of the plurality ofprocesses as to progress of the initiated one of the plurality ofprocesses at the given node. 7: The method of claim 7, wherein the stepof logging the error message further comprises the step of logging thepredetermined process step wherein the initiated one of the plurality ofprocesses was determined to have not been completed during thepredetermined process completion time. 8: The method of claim 8, andfurther comprising the steps of: storing information regarding theinitiated one of the plurality of processes, such that the initiated oneof the plurality of processes can be reinitiated at the given one of thenodes; and reinitiating the initiated one of the plurality of processesdetermined to have not been completed during the predetermined processcompletion. 9: The method of claim 1, and further comprising the step ofmonitoring the length of time that the initiated one of the transactionsrequires for completion. 10: The method of claim 10, wherein the step ofmonitoring the length of time that the transaction requires forcompletion comprises the steps of: initiating a process timer when theinitiated one of transactions has been initiated; comparing the value ofthe timer with a predetermined transaction completion time for theinitiated one of the transactions; if not completed, logging an errormessage to the central location that the initiated one of thetransactions has not been completed within the predetermined transactioncompletion time. 11: The method of claim 11, wherein the step of loggingthe error message further includes sending a notification to apredetermined location that the initiated one of the transactions hasnot been completed during the predetermined transaction completion time.12: The method of claim 1, where there is a plurality of data associatedwith each of the transactions and transaction parameters associatedtherewith to define the transaction in the system, and furthercomprising the step of storing the plurality of data associated witheach of the transactions and transaction parameters associated therewithin an archive. 13: The method of claim 13, and wherein the step oflogging comprises logging a pointer to the plurality of data associatedwith each of the transactions and transaction parameters associatedtherewith stored in the archive and information associated with theprogress of the transaction on each of the intermediate nodes. 14: Themethod of claim 14, and further comprising filtering the loggedinformation and storing the filtered logged information in an externallog and allowing restricted access thereto by an external system forreview thereof.